Книга по клиент - серверным БД.

← →
Игорь Шевченко © (2006-04-13 23:23) [40]

Суслик © (13.04.06 23:13) [36]

А что касается консультантов, то они тоже всякие бывают. Может вам "экземпляр неудачный" попался ?

← →
Суслик © (2006-04-13 23:37) [41]

> Может вам "экземпляр неудачный" попался ?

Мы в этом проекте участие хвала аллаху не принимали :)

← →
Игорь Шевченко © (2006-04-13 23:39) [42]

Суслик © (13.04.06 23:20) [39]

Мы все-таки о разном. Я о том, что суть предметной области не может однозначно диктовать способ взаимодействия с СУБД, количество звеньев, и т.д. Ты же понимаешь, что одну и ту же задачу предметной области можно решить правильно разными путями. Способ взаимодействия определяет масштабируемость, не более того. Грубо говоря, если у тебя один пользователь вводит 1000 записей в день, или 1000 пользователей вводят каждый по 1000 в день, то здесь и надо искать различие, но задача-то при этом с точки зрения предметной же области, останется все той же - РСФО, ЗБСУ НУ и прочие страшние слова.

← →
Суслик © (2006-04-13 23:44) [43]

> Игорь Шевченко © (13.04.06 23:39) [42]

Тебе, наверное повезло, с тем, что ты много знаешь про предметную область. У нас не так, причем, я не могу даже теоретически представить кто виноват - жизнь такая.

← →
Игорь Шевченко © (2006-04-13 23:57) [44]

Суслик © (13.04.06 23:44) [43]

> я не могу даже теоретически представить кто виноват

А представить, что делать или едят ли курицу руками, ты можешь ? :)
(Это три извечных вопроса, если что - кто виноват, что делать и едят ли курицу руками).

Вот возьми того же Фаулера, как ты полагаешь, он обладает самыми углубленными познаниями во всех предметных областях, с которыми ему приходилось сталкиваться, или все-таки достаточно знать набор шаблонов (или паттернов, как сейчас модно говорить) и уметь раскладывать большую проблему на ряд маленьких с известными решениями и есть слона по кусочкам ?

← →
Суслик © (2006-04-14 00:06) [45]

> Игорь Шевченко © (13.04.06 23:57) [44]

Я тебе на это отвечу так - дайте мне консультанта, способного ответить на специфические вопросы бухучета (уж не буду щеголять терминами :)), и я сделаю все хорошо, правильно, красиво.
Но нет таких людей, нет. У нас рядом сидит аудиторская фирма (наша же фирма). Люди весьма продвинутые. Но даже они на вопросы отвечают уклончиво. Спрашиваешь, а как должно быть, какой алгоритм. Они - ну вроде такой, он наиболее логичен. Им то понятно легче - они пишут бумажки, сегодня так написал, завтра иначе. Будут проблемы - при наших законах в суде можно защитить любую точку зрения (опыт был). А мне же программу делать. А она не может работать по теоретиковероятносному алгоритму - алгоритм должен быть детерминирован.

Поэтому в Фаулером сравнение считаю некорретным. Его успех основан на знании предметной области. Не зная ее хорошо невозможно сделать систему. В этом я уверен. Конечно, можно сказать, что можно написать такую систему, которая бы легко адаптировалась к задаче. Но это можно сделать в рамках разумного. Иначе ты напишешь R3, Скалу или BAAN (крупные erp системы), которые могу все - но это реальные монстры.

← →
Игорь Шевченко © (2006-04-14 00:29) [46]

Суслик © (14.04.06 00:06) [45]

Я очень извиняюсь, в бухгалтерии как в санскрите, но неужели нет открытых источников информации ? В том же тырнете, например, опять же, Ашот Товмасян вроде занимается работами аналогичного профиля. Неужели так все секретно ?

← →
Суслик © (2006-04-14 00:31) [47]

> Игорь Шевченко © (14.04.06 00:29) [46]

Нет. Вернее все есть. Есно у меня стоят все самые новые и даже еще не действующие, но принятые законы.
Но аудиторы со 30летним стажем не могут сказать точно, что значит та или иная фраза в законе. Понимай как хочешь.

← →
Игорь Шевченко © (2006-04-14 00:44) [48]

Суслик © (14.04.06 00:31) [47]

Это я все понимаю, но на подобные вещи вроде юристы существуют, законы толковать. Бухгалтера-то как-то умудряются работать, и вроде у них даже получается. Значит, они для себя алгоритм находят, верно ? А раз находят, то наверняка в том же тырнете делятся :)

← →
Суслик © (2006-04-14 00:59) [49]

> Игорь Шевченко © (14.04.06 00:44) [48]

Правильно излагаешь.
Но! Вот представь, если некий закон. Некие трактовки неоднозначны. На это существуют "толкования" разных уважаемых людей. Эти люди не министр финансов, не министр налогов и сборов, не дипутаты, принявшие закон. Это просто очень уважаемые люди (если не ошибаюсь есть такая фамилия Шеремет). То что они пишут это их личное мнение. На него можно полагаться, наверное, а может нельзя. Сделаешь как они пишут, придут к заказчику из органов, возмут за ж, с тебя спросят, а ты им - ну типа так писали "токователи". Какие такие писатели - закон видишь, вот тут написано, что этого делать нельзя (а это и не написано, а только подразумевалось под витьеватостью фраз).

Т.е. хочу сказать вот что - система бухучета некоторые (конечно не все) моменты позволяет трактовать вольно (кончено в рамках границ). Поэтому для принятия определенной трактовки должа быть в наличии определенная личность, и не наемный юрист, а человек принимающий решения или топманагер, который и будет нести ответственность за свое решение.

← →
Sergey Masloff (2006-04-14 06:29) [50]

Суслик © (13.04.06 22:59) [32]
Я уже проснулся ;-)))

>Тогда вот что скажи (если можно). Архитектура:
>1. На клиент в какое-то поле произошел ввод
>2. Ввод отправился на сервер
...
>1. Сразу кидаете в таблицы?
>2. Или храните в спец. таблицах и кидаете в таблицы после подтверждения >ввода документа?

>Если п. 1, то как у вас сделана отмена ввода. Например, агент начал >править полис, но передумал (мало ли).
Два вида
1) При пересчете никакие данные в базе не меняются. Клиенту присто приходит курсор с интересующими его данными.
2) Твой пример с полисом неудачен. Полис или еще не был оплачен - тогда прямо сразу все меняется в таблицах и у клиента на экране актуальная серверная информация. Или его состояние было зафиксировано (он выпущен) и больше не меняется. При возникновении новых данных старые не удаляются никогда - только записываются новые так что это не проблема. Вообще на эту тему книжку можно написать но вот тебе ОЧЕНЬ примитивный пример.

Вот пришел страховать машину. Водители ты и жена у жены нет стажа. За это тариф выше. Ты оплатил полис и возникло условие -
Полис №ААА действует с 1.01.2006 по 31.12.2006
Условие 1 автомобиль ламборджини дъябло, условие действует с 1.01.2006 по 31.12.2006 лимит ответственности 700000 у.е. премия (ты оплатил) 30000 у.е.

Через месяц ты пришел и говоришь - ну ее на фиг эту жену водить не умеет пусть на такси ездит. Исключаем ее. Агент создает АДДЕНДУМ - дополнительное соглашение к полису. Имеем:

Полис №ААА действует с 1.01.2006 по 31.12.2006
Аддендум 1 к полису Полис №ААА действует с 1.02.2006 по 31.12.2006
Условие 1 автомобиль ламборджини дъябло, условие действует с 1.01.2006 по (ВНИМАНИЕ!) 31.01.2006 лимит ответственности 700000 у.е. премия (ВНИМАНИЕ!) (30000 у.е./365 * 31) условие отменившее данное - условие 2

Условие 2 введено аддендумом 1, автомобиль ламборджини дъябло, условие действует с 1.02.2006 по 31.12.2006 лимит ответственности 700000 у.е.
премия (25000 у.е./365 * (365-31))

Как видишь, имеем усложнение схемы но сразу две выгоды
1) На любую точку действия полиса без пересчета знаем его состояние. Грубо говоря делаем сечение на дату все условия которые им (сечением) режутся - действующие на данную дату
2) Удобство отмены. Ты передумал - отлично мы удаляем (конечно не удаляем - только меняем статус на аннулирован) аддендум. При этом удаляются все условия введенные аддендумом. При удалении условия просматриваются и восстанавливаются все условия имевшие ссылку на удаляемое как на условие прекратившее данное. В "твоем" случае условие 2 исчезнет а условие 1 снова растянется на весь год с соответствующим увеличением суммы.

Хоть что-то понятно? Я бы лично сам не понял ;-))) Тут надо долго и нудно на бумажке рисовать по переписке фиг объяснишь...

← →
Игорь Шевченко © (2006-04-14 10:19) [51]

Суслик © (14.04.06 00:59) [49]

Странно вы программы пишете. Ну да ладно.

← →
BiN © (2006-04-14 10:33) [52]

Пр
> Суслик © (14.04.06 00:59) [49]
>
>
> Правильно излагаешь.
> Но! Вот представь, если некий закон. Некие трактовки неоднозначны.
> На это существуют "толкования" разных уважаемых людей.
> Эти люди не министр финансов, не министр налогов и сборов,
> не дипутаты, принявшие закон. Это просто очень уважаемые
> люди

Программный продукт =
разработчик(архитектор, проектировщик, кодировщик) +
эксперт (бухгалтер, юрист, министр финансов).

Нет эксперта - нет варенья.

← →
Суслик © (2006-04-14 12:07) [53]

> Странно вы программы пишете. Ну да ладно.

В России живем.
Ты занимался ли разработкой именно бухсистем?

> [52] BiN © (14.04.06 10:33)

Ты говоришь именно про бухсистемы или вообще про то как надо делать? :)
Ты занимаешься разработкой именно бухсистем?

====================

> [50] Sergey Masloff (14.04.06 06:29)

> Хоть что-то понятно? Я бы лично сам не понял ;-))) Тут надо
> долго и нудно на бумажке рисовать по переписке фиг объяснишь...

Понял ну почти все - не первый год замужем :) Очень хорошо все рассказал (могу свою страховую фирму открывать :))
Но все же вопросы есть.

В твоем примере:
1. я заплатил 30000 уе в качестве премии.
2. из них "потратил" за первый месяц 2547,95 уе
3. т.е. у меня осталось 27452,05 уе.
4. потом я изменил условия срахования таким образом, что должен до конца года заплатить 25000 /365 * (365-31) = 22876,71.
5. т.е. твоя контора вернет мне 27452,05 - 22876,71 = 4575,34 уе.

Тут я вроде все верно понял.
Вопросы:
1. если отменить условие 2, то нужно будет доплатить? Верно ведь? Это то вы где храните? Т.е. где храните факт доплаты? Т.е. нужно будет менять исходный полис? Или будет еще аддендум с допалатой. Этого я из твоего рассказа не понял.
2. Правильно ли я понял, что вы вообще оплаченные документы (полисы) не меняете?

← →
Суслик © (2006-04-14 12:09) [54]

> [50] Sergey Masloff (14.04.06 06:29)

Т.е. я не могу понять, как соотносится фраза

> При возникновении новых данных старые не удаляются никогда
> - только записываются новые

и

> При удалении условия просматриваются и восстанавливаются
> все условия имевшие ссылку на удаляемое как на условие прекратившее
> данное

Т.е. они несколько противоречивы.

← →
Игорь Шевченко © (2006-04-14 12:14) [55]

Суслик © (14.04.06 12:07) [53]

> В России живем.

Отмазка не канает.

> Ты занимался ли разработкой именно бухсистем?

Мне достаточно того, что этим занимается 1С, причем успешно

← →
Суслик © (2006-04-14 12:23) [56]

> Мне достаточно того, что этим занимается 1С, причем успешно

Факт не канает :) т.к. основан на неверной информации.
Сама по себе 1с с базовой поставке требует адаптации. Для обслуживаемого нами бизнеса она на подходит. Фактчески "боевая" система 1c это система написанная франчайзингом с нуля (или почти с нуля) на основе фареймворка (среды разработки), предоставляемого 1с.
Как ты думаешь почему столько франчайзингов и программистов 1с? Все очень просто - бухсистема постоянно требует поддержки, причем практически еженедельной или даже чаще. Например в ближайшем времени вступят в силу поправки к налоговому кодексу - изволь делать. Потом еще будут порпавки, потом еще. Притом, что некоторые моменты не могут однозначно истолковать представители аудиторской профессии (или будем оспаривать их компетенцию?). Вот такая жизнь - пишешь, как понял, потом переписываешь и т.д. Так и 1с живет, вернее из внедренцы в лице франчайзингов.

← →
Суслик © (2006-04-14 12:25) [57]

Еще хотел добавить к фразе

> Так и 1с живет, вернее из внедренцы в лице франчайзингов.

Если они так не живет, а, например, пишут раз и навсегда "правильно" по советам "эксперта", то значит они плохо делают свою работу, вернее не делают ее, т.к. поправки выходят постоянно.

← →
Суслик © (2006-04-14 12:31) [58]

2ИШ
Еше хотел добавить.
У на не первый раз возникает разговор на эту тему. И не первый раз мне не удается объяснить свое мнение.
Вот представь, что у тебя есть эксперт А, сидящий в соседней комнате, жуткий профи. И есть эксперт Б сидящий в белом доме. Эксперт А читает бумажки эксперта Б. При том, что эксперт Б в общем-то не всегда профи. Но от услуг эксперта Б вы отказаться не можете. Эксперт А не всегда понимает, что говорит ему эксперт Б, т.к. тому пофигу - он на работе, ему нужно работать, деньги, деньги. Все остальное его не очень волнует. Как ты думаешь, какая до тебя в итоге дойдет информация? Каково будет ее качество и конструктивность?

Конечно, не все так плохо. Но есть моменты, где именно так - делай как знаешь на свой страх и риск.

← →
Игорь Шевченко © (2006-04-14 12:48) [59]

Суслик © (14.04.06 12:31) [58]

Добавь в программу настройку - сними с себя ответственность и переложи ее на конкретного пользователя - что может быть проще ?

← →
Суслик © (2006-04-14 13:00) [60]

> Добавь в программу настройку - сними с себя ответственность
> и переложи ее на конкретного пользователя - что может быть
> проще ?

Игорь, ты прав на все 100%. Кто же спорит.

Для того, чтобы добавить настройку нужно понимать набор сущностей которые могут быть изменены. Ты же должен понять набор настроек? Если не понимать сущности, то как можно формаровать набор настроек? Логично?
Понимаешь ли, автоматизированный бухучет это не отражение действительности, сформированной только на потребностях бизнеса. Плюс к этому, это отражение законов, которые пишутся не всегда профессиональными людьми. Вернее может и профессиональными, но далекими от автоматизации. Пример - форма печати, диктуемая законом в которой есть 19 столбцов на одной странице в каждый из которых нужно занести, напиример число, в общем случае с 10 знаками. О какой продуманности тут можно говорить? Пиши форму как хочешь - дело твое, но набор столбцов должен быть таким.

Есть много других элементов закона, которые не поддаются однозначной алгоритмизации.

Есть системы в которых все вынесено в настройки - наприрмер sap r3 (это, правда, не бух система, а erp система, но не суть). В ней есть любые настройки. Там вообще программировать не надо - только мышкой кликай. У меня знакомый человек работал там. Он говорит, что за 3 года внедрения знал ровно 10% процентов от этой системы. Это говорит о монстроподобности таких систем. Реально ли такую написать? Не думаю.

Кстати по поводу доступности настроек пользователям. Кто реально данными настройками пользуется далеко не пользователи, а люди с зарплатами (понимаю, что не говорит ни о чем) до 4кб в месяц. Плюс к этому, конечно прилагается, соответствующий уровень знания. Ты предлагаешь такую работу взвалить на плечи пользователя?

Хотя, как мне кажется, для бухсистем такое вообще не применимо. Фиг такое сделаешь, т.к. в бухучете вариации зависимостей и алгоритмов очень большие. Пример. Сейчас (вроде в начале года поправки к Налоговому кодексу были) можно списывать 10% стоимости основного средства при постановке на учет. Разве можно это предугадать? Ну допустим даже можно - ввести настройку - столько процентов можно списать сразу. Но тут не ясно - куда их списывать: в амортизацию или в расходы. Тоже настройку делать? Так еще может быть такое, что данные расходы вообще не уменьшают налогооблагаемую прибыль (глупость, но мало ли) или еще какие условия? Поэтому набор настроек становится невменяемым - легче код написать.

← →
BiN © (2006-04-14 13:12) [61]

> Суслик © (14.04.06 12:07) [53]
>
>
> > [52] BiN © (14.04.06 10:33)
>
> Ты говоришь именно про бухсистемы или вообще про то как
> надо делать? :)
> Ты занимаешься разработкой именно бухсистем?

Говорю про разработку любых приложений на заказ.
Занимался в том числе и адаптацией все тех же 1с-предприятие/торговля-склад.
ТЗ пишется с участием эксперта от заказчика. Понятие "эксперт" - здесь весьмя условное и подразумевает человека, способного ответить на вопрос, что именно хочет заказчик вплоть до цвета тени мышки.
В случае же, если заказчик не знает чего хочет, программист должен или отказаться от проекта или (обычно при солидном инвестировании) суметь внушить заказчику желания оного.
Ясно, что бухгалтерия - скользкая тема и потому так много мальчиков-полупрограммистов сидят в малых и не очень фирмах, дописывая налету разные Trade Assistant-ы, 1С-ы и т.п. Чаще всего инициатором подобных изменений в программах выступают только что пришедшие бухгалтера или контрактники-аудиторы ("А вот мне нравится, когда так", "Там, куда мы сдаем, сказали, что нужно считать так" и т.д.).
Повторяю, это происходит в основном в малых фирмах, где нет профессионального юриста, способного, если надо, отстаивать каждую цифру.

← →
Игорь Шевченко © (2006-04-14 13:13) [62]

Суслик © (14.04.06 13:00) [60]

Мы с тобой о разном говорим. Ты все пытаешься человеческий фактор в процесс проектирования привнести. Ты его наоборот оттуда изыми, сразу проще будет.

← →
Суслик © (2006-04-14 14:06) [63]

> Повторяю, это происходит в основном в малых фирмах, где
> нет профессионального юриста, способного, если надо, отстаивать
> каждую цифру.

Согласен на все 100%. Ты прав. Я хотел это добавить, но упустил.
Уверен, что в больших конторах есть юристы, способные принимать решения, т.е. уже быть не только юристами, а нести ответственность за принятие решений. В маленьких конторах такого обычно, наверное, нет. Есть один руководитель, который общается с заказчиком и пытается от него понять что ему нужно.

Бухгалетерия во многом еще скользкая тема потому, что до нее у реального руководства дела нет. Им главеное, чтобы налоговая за ж не взяла. Все. Поэтому обслуживая контору (а мы кроме разработки еще и обслуживаем, я вообще сомневаюсь, что бывает бухгалтерия без обслуживания) ты вынужден общаться с людьми, которые не принимают решения - с теме же главбухами. И во многом страаашно далеки от аналитической мысли, нужной разработчику.

> [62] Игорь Шевченко © (14.04.06 13:13)

Действительно о разном говорим. Я те говорю, что бухгалтерия не бывает без человеческого фактора (даже дока-в несколько привел), а ты говоришь, что бывает. Тут истины не найдешь. Т.к. я уверен, что в бухучете такого не бывает (т.е. разработка по "правилам" без чел. фактора), то у меня выход один - на заниматься разработкой бухсистем вовсе :)

← →
Игорь Шевченко © (2006-04-14 14:19) [64]

Суслик © (14.04.06 14:06) [63]

> то у меня выход один - на заниматься разработкой бухсистем
> вовсе

Тоже выход. Потому что (ты уж меня извини, конечно), сдается мне, что при таком подходе вряд ли получится система, которой можно будет эффективно пользоваться. На Excel"е посчитать проще получится.

← →
Суслик © (2006-04-14 14:22) [65]

> [64] Игорь Шевченко © (14.04.06 14:19)

> ты уж меня извини, конечно

Да не проблема, тем более, что система работает и имеет огромные перспективы.

← →
Игорь Шевченко © (2006-04-14 14:31) [66]

Суслик © (14.04.06 14:22) [65]

Удачи :) В перспективе :)

← →
Суслик © (2006-04-14 14:33) [67]

2ИШ
Прикольно, поговрили, а я даже подзабыл в чем причина спора.
-------------
Ты мне вот что скажи, неужели у вас есть такие эксперты, способные ответить на любой вопрос по бизнес-логике? Неужели не бывает разночтений?

← →
Игорь Шевченко © (2006-04-14 14:42) [68]

> неужели у вас есть такие эксперты, способные ответить на
> любой вопрос по бизнес-логике

Конечно.

Да, не там я работаю.

[17] Суслик © (13.04.06 21:55)
> Например, у нас сейчас решается задача параллельного ведения
> учета по МСФО (международный стандарт) + РСБУ (российский
> стандрарт) + НУ (налоговый учет). Не знаю, насколько ты
> близок к бухгалтерии, но уверяю, что данная задача очень
> сейчас востребована. Настолько востребована, что лучше ее
> сделать с медленным сервером, чем не сделать с быстрым.

Моя твоя непонимай.
Там где я раньше работал, делалось так: МСБУ, РСБУ и НУ - разные планы счетов.
Проведение любого документа - ХП на сервере, почти для каждого типа документа своя, а там ужо от тебя зависит, что эта ХП будет делать, по какому плану счетов и какие проводки.
Без всяких J2EE и логики где-то еще помимо сервера БД.

> МСБУ, РСБУ и НУ

Мы от этой идеи отказались. Основной мотив, что на счетах МСФО и НУ можно держать только разницы. Для того, чтобы понять, например, сальдо по Основным средствам нужно взять сальдо по 01 + сальдо по НУ01
И т.д. На самом деле это оказывается выгодно тем, что по НУ и МСФО нужно держать немного записей.

Когда я плотно работал с МСФО (2003 год), то тот, кто мне ставил задачи утверждал, что в МСБУ без сложных проводок (когда, например, одна проводка, но 2 счета по дебету и 3 счета по кредиту) никак нельзя обойтись, а в РСБУ - без проблем. Соответственно, непонятно, какие разницы и в каком виде там вы будете хранить?

Впрочем, не имеет значение, что там держать - разницы, или все необходимое, главный вопрос в другом: как перенос логики с серевера БД на сервер приложений позволяет ускорить процесс разработки и внесения изменений в эту самую логику?

> но 2 счета по дебету и 3 счета по кредиту

Это гааповская форма проводки. Их всегда можно заменить российскими продовками.
Например, в РСБУ

Расчеты с поставшиком (часть)
1000 26 60
200 19 60

В гаапе тип такого было бы (я не помню точно как там записывается)

1000 26 -
200 19 -
1200 - 60

По сути одно и то же.

> Впрочем, не имеет значение, что там держать - разницы, или
> все необходимое, главный вопрос в другом: как перенос логики
> с серевера БД на сервер приложений позволяет ускорить процесс
> разработки и внесения изменений в эту самую логику?

Во. На этот вопрос забыл ответить :)
Тут все просто. Работая в среде ООП при качественном первичном проектировании фреймворка (в j2ee это уже сделано, нужно только адаптировать это под твои цели) ты получаешь средства заточенные под тебя, на языке высокого уровня. Поди плохо :)

ЗЫ. Я кстати j2ee не юзаю - у нас свой доморощенный аналог.

> Тут все просто. Работая в среде ООП при качественном первичном
> проектировании фреймворка (в j2ee это уже сделано, нужно
> только адаптировать это под твои цели) ты получаешь средства
> заточенные под тебя, на языке высокого уровня

Свежо предание о серебряной пуле, да верится с трудом.

> [75] Игорь Шевченко © (14.04.06 16:33)

Ну что значит "вериться"?
У тебя есть сомнения, что работать в ООП середе в общем случае в крупных прилоежения (порядка 1млн самописных строк) проще, чем без ООП?
Не пойму я тебя.

[73] Суслик © (14.04.06 16:20)
Я тоже так думал. Но. Попробуй напиши обычными проводками тип такого:
д20 400р.
д26 600р.
д19 200р.
к60 450р.
к76 650р.

когда не два к одному, а два к двум, два к трем и т.д.?
:)

[74] Суслик © (14.04.06 16:30)
Ну, незнаю. Зачем ООП при проведении документа? Возможностей PL/SQL хватало за глаза, думаю, T-SQL тоже-бы хватило.

> д20 400р.
> д26 600р.
> д19 200р.
> к60 450р.
> к76 650р.

Пойми, это форма записи. Как к таковому МСФО она отношения не имеет. В МСФО несколько другие законы. Вот это да. Например, разный подход к лизингу. Точно не помню (я не эксперт), но в РСБУ кажется ОС полученные нами в лизинг стоят на балансе у нас, по МСФО нет (или наоброт).

> Ну, незнаю. Зачем ООП при проведении документа? Возможностей
> PL/SQL хватало за глаза, думаю, T-SQL тоже-бы хватило.

Знаешь, у нас так получилось, что изначально обладая гибкими возможностями ООП мы наплодили влякого удобнейшего функционала, от которого теперь отказаться не можем. Думаю, что данный функционал будет непросто сделать на SQL. Хотя вопро потребости в нем не очевиден. Возможно, что можно все делать проще так, чтобы все получалось на sql.

Суслик © (14.04.06 16:37) [76]

У меня есть сомнения в сути поста [74], кроме того, я увидел там слова "качественное первичное проектирование", а судя по твоим предыдущим постам о всяких там человеческих факторах, у меня зародились сомнения в качестве того самого проектирования.

> У тебя есть сомнения, что работать в ООП середе в общем
> случае в крупных прилоежения (порядка 1млн самописных строк)
> проще, чем без ООП?

Кстати, есть сомнения.

Книга по клиент - серверным БД. Найти похожие ветки