WiRucСогласитесь, что в данном подходе затыки значительно усилены за счет того, что Object является бутылочным горлышком.

Тоже саммое сказал и я, когда впервые увидел такой подход.

WiRucПричем тормозить будет вся система в целом, а не скажем работа с накладными.

Не факт - работа системы ни есть вставка в одну таблицу. ;)

WiRucУ вас промышленная эксплуатация такой системы? Давайте тогда подробности...

Что Вас конкретно интересует?

Бывший казначей2 - реализация была чуть менее ортодоксальной - на уровне представлений и хранимок все-таки прослеживался скорее РСУБД-шный подход, что в сочетании с такой структурой таблиц действительно обеспечивало высокую гибкость.

Золотые слова. Именно такая реализация и используется.

WiRuc pkarklinЧто Вас конкретно интересует?
Общее описание: что за система (предметная область), какая глубина иерархии, как реализованы массовые операции над сущностями, количество пользователей, количество транзакций в секунду, были ли проблемы с производительностью и как их решали.
Больше всего меня интересует Ваше мнение в сравнении с традиционным подходом. Вот скажем, реализовали бы такую систему в стандартном варианте, в чем бы мы выиграли, а в чем проиграли.

1. Ну, скажем так - вся логистика + часть документа оборота + часть бухгалтерии + бюджетирование + еще кой-чего по-немногу. Система то развивается. :)
2. Глубина - не более 7.
3. Все реализовано через хп.
4. Пользователей (работающих) не много - около 100, но большую часть работы (читай нагрузки) создают роботы.
5. В среднем (по перфоманс монитору) - 30.
6. Пробемы с производительностью в основном связаны не с выбранной архитектурой.

При реализации "стандартным" подходом сильно бы проиграли на сроках реализации решений, ибо огромная часть логики реализована в ядре системы. На производительности -такой подход врядли сильно сказался бы отрицательно, даже, IMHO, наоборот. Ибо "узких мест" - единицы, а они не разбросаны по все системе и их легче "отловить" и оптимизировать.

WiRucНапример, как мне решить такую задачу: Есть 3-х уровневая иерарахия. Для итоговой сущности я хочу сделать выборку по 3 полям, по одному полю из каждого уровня иерархии.

Любая сущность в системе (состоящая из от 1 до N таблиц) представлена представлением. (Прошу прощения за каламбур). Нет прямого доступа к таблицам. Индекс будет построен на представлении.

WiRucНу, это совсем другое дело. Разнесение сущностей на 1-1 в принципе практикуется (скажем, контрагенты -> физ.лица, юр. лица).

Ну, так и сделано, в принципе, только за одним исключением, что есть одна единственная "родительская" сущность.

LRВЕРО - единый реестр объектов

Ну, тогда уж так: Ставка на ВЕРО ;)

DeColo®esКонечно, это решение не должно начинаеться с таблицы Object, если только нет нужды ССЫЛАТЬСЯ на сущности класса ТАКОГО уровня наследования.

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

Коллеги. Наличие единой базовой сущности не является самоцелью. Рассмотрим некоторые классические потребности любой информационной системы:

Идентификация сущности в системе. На предмет сурогатный\естественный ключ уже не мало копий сломано, однако, в большинстве случаев выбор склонятеся в сторону того или иного сурогатного ключа. Теперь сделаем шаг дальше... А почему бы, если каждая сущность имеет сурогатный ключ не иметь единое глобальное для системы протсранство идентификаторов сущностей? Чем это может помочь в дальнейшем проектировании:

1. Уникальность идентификатора объекта и единое пространство идентификаторов всех прикладных объектов в системе - само собой
2. Унифицированное управление схемами состояний и правилами переходов между состояниями объектов;
3. Унифицированное управление правами доступа к объектам, включая реализацию RLS;
4. Общий механизм поддержки расширяемых атрибутов;
5. Единую систему журналирования событий;

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

А теперь представьте себе реализацию такого меанизма при класическом подходе, когда каждая сущность представлена отдельной таблицей, не имеющей "общего предка". Реализацию всех пунктов, описанных выше, придеться повторять для каждой отдельной сущности. Согласитесь, не слишком благодарный труд. Лучше это время потратить на проектирование и реализацию поведенческих характеристик прикладных объектов в системе.

Все описанное выше, конечно, не является ООП в классическом его понимании, но что-то очень похожее по своей идеологии и поведению. IMHO.

Обратите внимание, что при таком подходе все равно нет отхода от реляционной струтктуры.