2 DeColo®es

Целью моего поста не являлась (и не будет являтся) агитация всех и вся за использование такого механизма. Я изложил свое видение вопроса и его плюсы.

DeColo®esА зачем оно нам надо? :) Для глобальных уникальных вполне подходит GUID. Ставить этот довод на первое место - не стоит, мягко говоря.

Например, для того, чтобы было возможно найти и открыть любой объект в системе по его ID. Если у Вас гуиды (или любые идентификаторы) будут разбросаны по не связанным таблицам, то Вам, в случаи добавления новой сущности придеться изменять часть кода, ответственного за ее поиск в системе. В случаи с единым родителем в этом нет необходимости.

DeColo®esНе в одних только состояниях щассте. :( Да и статусы как правило очень специфичны для разных сущностей либо их будет такое количество, что работать будет просто неудобно.

Вы совершенно правы, что схема состояний м.б. как уникальна для каждой сущности, так и использоваться несколькими. Но зависимость поведения объекта от его состояния и действия, выполняемые в системе при смене состояний - очень мощный фреймворк для реализации поведенчиских характеристик объекта в системе.

DeColo®esВ нашей системе этот универсальный механизм прекрасно существует без уникальных идентификаторов. :)

Хм... Готов с интересом расмотреть Ваш вариант решения (с не связанными таблицами) следующей задачи. Пусть появлятся какая либо дополнительная сущность. Какое кол-во объектов бд, кроме таблицы самой сущности Вам необходимо будет создать для реализации RLS? И самое главной, как потом "корректно" встроить эти объекты в систему глобального поиска (просмотра, реадктирования, удаления) объекта в системе с учетом RLS?

DeColo®esУ нас она только в одной базе она присутствует в нескольких СПЕЦИФИЧНЫХ для каждой сущности реализациях. Но если бы все загонялось в самую универсальную - тормоза были бы те еще.

Можно уточнить - о каких тормазах и в каком месте Вы говорите, учитывая что расширенная атрибутика работает на базовом уровне системы?

DeColo®esИ что она журналировать будет? Изменение некоего абстрактного общего для всех сущностей статуса? Но этого маловато.

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

DeColo®esНа самом деле, универсальные механизмы в п2-4 - действительно нужны. Но для них совсем необязательно для всех объектов заводить общего предка. Хотя его существование в общем-то ничем не мешает, но может стать бутылочным горлышком.

Могу еще раз только повторить - я не приподношу это решение, как серебряную пулю.

2 GreenSunrise

Кое что описано суть выше, кое что уточню.

GreenSunriseА если у меня список состояний и матрица переходов разная для "предка" и "потомка"? Полноценного наследования с виртуальными функциями все равно нет, поэтому базовая таблица тут особо не поможет.

Именно так. Они разные. И есть "виртуальные функции" - хп ObjectSetState и ObjectExecStateTransit. Все. Далее механизм смены состояний работает вне зависимости от кол-ва прикладных объектов и их схем состояний.

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

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

Извиняюсь, допишу чуть позже... В офисе свет вырубают...

Коллеги. Свет, наконец то, включили. Отвечу всем по-порядку...

GreenSunriseИ опять-таки полегче. Если вы журналируете только факт изменений и вас интересует только id журналируемой сущности, то базовой таблицы достаточно. А меня вот интересует изменение значений полей (это не для примера, это в реальной системе у нас так). И фига мне с вашей базовой таблицы? У меня же по-прежнему нет виртуальной функции LogMe, которая в базовом классе сделает одно, а в наследнике другое, да еще и позволит обратиться к методу предка. И опять же, у нас триггера журналирования делаются кодогенерацией, поэтому никаких затруднений с расширением таблицы мы не испытываем.

Ну, чтоб не быть голословным приведу просто скриншот логов одного из объектов (документ)

И лог контрагента. Все, что логгируется реализовано на базовом уровне.

LRОдна крайность - хранить(регистрировать) в "стержневой" только ID и тип, вторая - напихать туда побольше "якобы общих" полей, вероятно, должна быть какая-то "золотая серединка" (зависящая от назначения системы)?

Ну, скажем так. Найдена некая "золотая середина", достаточная для реализации базового функционала системы.

LRнапример, зачем смешивать метаданные и данные в одной таблице(ведь это приводит к потере корректности ссылочной целостности) и т.п.?

В базе существует ссылочная целостность. Метаданные и данные в одной табоице не смешаны. Если посмотреть внимательно на структуру бд - классическая реляционная модель.

ShurgenzНасколько я успел в этой всей схеме хоть что-то понять, там именно легкая, а может и не очень легкая степень денормализации...

Абсолютно никакой денормализации. Повторяю, классическая реляционная модель.

ShurgenzПо крайней мере, насколько я понял... в случае иерархии с n-ным уровнем, любые изменения состояния верхнего члена иерархии затрагивает всех потомков, грубо говоря, происходит инсерт апдейт или удаление всех потомков, в зависимости от того, что с предком произошло. Это DML, затратная DML. Но от того, что информация по всему дереву раскрыта, то селекты там простые, и в общем то немедленные от этого.
Извращенная логика, как мне опять же объяснили, разрешается путем добавления индексных полей на том или ином уровне иерархии объекта...

Ничего подобного не происходит. Никаких DML - упаси господи.

DamirSПоправьте, если не прав.

Вы глубоко не правы.