Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl      все
 Re: ООП на сервере  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
pkarklin
1. Уникальность идентификатора объекта и единое пространство идентификаторов всех прикладных объектов в системе - само собой

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

pkarklin
2. Унифицированное управление схемами состояний и правилами переходов между состояниями объектов;
Не в одних только состояниях щассте. :( Да и статусы как правило очень специфичны для разных сущностей либо их будет такое количество, что работать будет просто неудобно.

pkarklin
3. Унифицированное управление правами доступа к объектам, включая реализацию RLS;
В нашей системе этот универсальный механизм прекрасно существует без уникальных идентификаторов. :)

pkarklin
4. Общий механизм поддержки расширяемых атрибутов;
EAV. :) У нас она только в одной базе она присутствует в нескольких СПЕЦИФИЧНЫХ для каждой сущности реализациях. Но если бы все загонялось в самую универсальную - тормоза были бы те еще.

pkarklin
5. Единую систему журналирования событий;
И что она журналировать будет? Изменение некоего абстрактного общего для всех сущностей статуса? Но этого маловато.
Или расширенных атрибутов? Если атрибут объекта является "справочным", а не "бизнес" (вряд нормальные люди ли будут загонять бизнес-атрибуты с интенсивной обработкой в EAV) - журналировать его может и нужно, но журналирование специфичных, хранящихся в отдельных таблицах атрибутов - тем более. То есть вместо одной процедуры журналирования будет 2.

На самом деле, универсальные механизмы в п2-4 - действительно нужны. Но для них совсем необязательно для всех объектов заводить общего предка. Хотя его существование в общем-то ничем не мешает, но может стать бутылочным горлышком.
13 мар 07, 11:17    [3890862]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
2 DeColo®es

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

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


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

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


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

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


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

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


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

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


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

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


Могу еще раз только повторить - я не приподношу это решение, как серебряную пулю.
13 мар 07, 11:45    [3891061]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Я не говорю ничего ни за, ни против наличия базовой таблицы. У нас в свое время была такая идея - сделать базовую таблицу для сущностей, но от этого отказались - побоялись именно того самого бутылочного горлышка.

Мне не нравится только употребление термина ООП в данном контексте. От ООП там 5%.

Теперь по упомянутым пунктам
pkarklin
1. Уникальность идентификатора объекта и единое пространство идентификаторов всех прикладных объектов в системе - само собой

Да. Это есть. Но это также может быть легко решено другими способами без базовой таблицы. Например, как WiRuc написал.

pkarklin
2. Унифицированное управление схемами состояний и правилами переходов между состояниями объектов;

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

pkarklin
3. Унифицированное управление правами доступа к объектам, включая реализацию RLS;

+1 с WiRuc.

pkarklin
4. Общий механизм поддержки расширяемых атрибутов;

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

pkarklin
5. Единую систему журналирования событий;

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

JET?
Потому, что, если средства разработки не поддерживают ООП, то эту поддержку придется писать самому.

Именно! Именно так. Если нет нормальной поддержки в языке - все равно все ручками пишется. И то, что вы описали, мне не кажется ни более гибким, ни более удобным и легким в эксплуатации, ни более расширяемым.

P.S. Я ни в коем случае ничего не критикую и не против никаких предлагаемых тут решений. Я просто не вижу в них смысла и выигрыша.
13 мар 07, 11:51    [3891112]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
2 GreenSunrise

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

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


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

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


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

Извиняюсь, допишу чуть позже... В офисе свет вырубают...
13 мар 07, 12:04    [3891234]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
LR
Member

Откуда: 8P8C
Сообщений: 2423
to pkarklin
Самым тонким и ответственным вопросом в этом деле мне представляется выбор полей/колонок для "стержневой" таблицы, т.е. какая информация должна содержаться в "стержневой" таблице, а какая выноситься в "хвостовые".
Одна крайность - хранить(регистрировать) в "стержневой" только ID и тип, вторая - напихать туда побольше "якобы общих" полей, вероятно, должна быть какая-то "золотая серединка" (зависящая от назначения системы)?

Вы можете поделиться с общественностью структурой таблицы dbo.Object? ;)

Возможно, как уже здесь отмечали, разумнее существование нескольких "стержневых" таблиц - по одной на каждое "крупное" пространство системы (по функционалу/назначению), например, зачем смешивать метаданные и данные в одной таблице(ведь это приводит к потере корректности ссылочной целостности) и т.п.?
13 мар 07, 12:15    [3891330]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
GreenSunrise
Member

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


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

Как именно это сделано, поясните, пожалуйста, я не понимаю.

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


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

Значит, я не понимаю понятия "расширенные атрибуты". Объясните, что это такое.
13 мар 07, 12:37    [3891516]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
LR +1
Если это возможно, очень хотелось бы увидеть конкретный код некоторых ХП, например ObjectSetState. Можно на мыло.

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

Я чет уже вообще ничего не понимаю Ну завели мы новый атрибут, но каким таким волшебным образом система узнает о НАЗНАЧЕНИИ этого атрибута и как его использовать в определенных ситуациях. Одно дело, если я на клиенте сразу автоматически могу его просматривать и изменять, тут никаких проблем и ООП для этого не нужен, а другое - его использование в серверной части (я не имею в виду журнализацию, RLS и прочие системные вещи).
13 мар 07, 12:39    [3891531]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
2 GreenSunrise
Вы не одиноки. Я с каждым постом понимаю все меньше и меньше
13 мар 07, 12:43    [3891569]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
DamirS
Member

Откуда:
Сообщений: 181
2 All
М-да... замучаетесь вы с этой структурой.
Еще и методы-хранимки для обьектов писать...
Умный народ (Дейт, Кодд) про ДЕнормализацию рассуждал: применять-не применять, какой выигрыш в производительности даёт...
А тут вот бесплатно получаем кучу join-ов при простой выборке 'обьекта'.

2Shurgenz
Что делать? Да отправить его на sql-ex.ru и разрешить внедрять свою систему только после прохождения 3-го оптимизационного этапа :)
13 мар 07, 12:53    [3891644]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
DamirS
Member

Откуда:
Сообщений: 181
кстати, есть еще статейка Анатолия Тенцера про обьектную модель.
Много шума было вокруг этой модели.
Кому интересно - поиск по 'Тенцер' в инете.
13 мар 07, 12:57    [3891677]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Shurgenz
Member

Откуда: Питер
Сообщений: 1938
DamirS
2 All
М-да... замучаетесь вы с этой структурой.
Еще и методы-хранимки для обьектов писать...
Умный народ (Дейт, Кодд) про ДЕнормализацию рассуждал: применять-не применять, какой выигрыш в производительности даёт...
А тут вот бесплатно получаем кучу join-ов при простой выборке 'обьекта'.

2Shurgenz
Что делать? Да отправить его на sql-ex.ru и разрешить внедрять свою систему только после прохождения 3-го оптимизационного этапа :)


DamirS
2 All
М-да... замучаетесь вы с этой структурой.
Еще и методы-хранимки для обьектов писать...
Умный народ (Дейт, Кодд) про ДЕнормализацию рассуждал: применять-не применять, какой выигрыш в производительности даёт...
А тут вот бесплатно получаем кучу join-ов при простой выборке 'обьекта'.

2Shurgenz
Что делать? Да отправить его на sql-ex.ru и разрешить внедрять свою систему только после прохождения 3-го оптимизационного этапа :)


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

Но на самом то деле, очень интересно про ObjectSetState и ObjectExecStateTransit услышать, и про атрибуты не очень понятно, но очень интересно
13 мар 07, 13:24    [3891907]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Naf
Member

Откуда: Москва
Сообщений: 2695
ООП нормально, но только не в том виде, как предлагают: не нужно общую таблицу объектов, достаточно абстрактных классов, описание есть, а реализации нет, а вот в потомках (и то не 1-го уровня) можно и реализовать задекларированное
13 мар 07, 13:39    [3892002]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
DamirS
Member

Откуда:
Сообщений: 181
Shurgenz

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

По-моему, у него всё в тяжелой форме :)
Для снижения нагрузки на сервер специально применяют денормализацию с целью избавиться от join-ов при выборке данных.
Грубый пример: Есть справочник Код-->Название Dict(code int primary key, name varchar(30))
В некоей таблице Table1 есть внешний ключ Dict. Денормализация: в Table1 вместе с внешним ключём Dict помещают так же Dict.name. Именно из-за того, что join - операция затратная

А при такой вот обьектной модели мы грузим сервер join-ами, которых можно избежать просто нормально спроектировав базу.

Поправьте, если не прав.
13 мар 07, 13:45    [3892037]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
DamirS
Member

Откуда:
Сообщений: 181
Ага, вот и обсуждение нашёл - страшно подумать - 2002 год!
обсуждение статьи Тенцера
В этой же ветке есть ссылки на сами статьи.
13 мар 07, 13:55    [3892098]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Naf
ООП нормально, но только не в том виде, как предлагают: не нужно общую таблицу объектов, достаточно абстрактных классов, описание есть, а реализации нет, а вот в потомках (и то не 1-го уровня) можно и реализовать задекларированное

Приведите пример, как это делается для баз. Не как это на плюсах пишут :-), а как это на T-SQL выглядит.
13 мар 07, 14:03    [3892142]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
DeColo®es
Member

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


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

Допустим, у меня пациенты. Классической поиск для них - по фамилии+инициалы либо номер амбулаторной карты.
Если мне нужно искать клиентов банка, то их ищут либо тоже по ФИО, либо по номеру счета или части счета - ИКК.
Если я ищу документ, скорее всего, это будет поиск по его номеру или имени контрагента.

То есть для каждого вида поиска мне нужно в любом случае писать уникальную процедуру, как на клиенте, так и на сервере. (Ну не хранить же данные счетов и клиентов в EAV, нужно же еще и поиск по значениям НЕКОТОРЫХ СПЕЦИФИЧНЫХ аттрибутов со специально заточенными индексами делать). Единственное, что может быть универсально - окошко на клиенте, показывающее список.

Кроме того, количество уникальных классов сущностей не так уж и велико и, тем более, их список не так часто пополняется. И работа по созданию новых процедур - тоже несложная - от различных методов кодогенерации до банального copy/paste и проблем вроде не вызывает ни у кого. Гораздо больше сил отнимают работы по оптимизации работы системы, которая сделана на универсальных механизмах и просто не справляется с хранением и обработкой данных в них. Например, попытаться ускорить импорт больших списков в условиях, когда просто несуществует "API" для создания множества объектов одной командой.

А универсальные механизмы для группировок, RLS и прочего прекрасно существуют и без базовой таблицы. Просто в каждом механизме прописывается кроме прочего еще и "класс" объектов, данных которых хранит этот механизм. А если идентификатор объектов - уникальный, то и класс прописывать не всегда обязательно.
13 мар 07, 14:05    [3892158]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Shurgenz
Member

Откуда: Питер
Сообщений: 1938
DamirS
Shurgenz

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

По-моему, у него всё в тяжелой форме :)
Для снижения нагрузки на сервер специально применяют денормализацию с целью избавиться от join-ов при выборке данных.
Грубый пример: Есть справочник Код-->Название Dict(code int primary key, name varchar(30))
В некоей таблице Table1 есть внешний ключ Dict. Денормализация: в Table1 вместе с внешним ключём Dict помещают так же Dict.name. Именно из-за того, что join - операция затратная

А при такой вот обьектной модели мы грузим сервер join-ами, которых можно избежать просто нормально спроектировав базу.

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


Джойнов там ровно столько, какой по счету это потомок + пара вспомогательных, опционально, для атрибутов и иерархий. А потомка глубже 4-го уровня придумать в реальной жизни трудновато (мне по крайней мере). Скажем, сущности user & group не есть предок и потомок, а есть иерархия, вроде бы, вроде бы... или старею, или все это для меня, привыкшего к теории множеств на практике, непривычно, а потому не совсем понятно.
13 мар 07, 14:06    [3892162]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
DamirS
Ага, вот и обсуждение нашёл - страшно подумать - 2002 год!
обсуждение статьи Тенцера
В этой же ветке есть ссылки на сами статьи.

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

pkarklin, а вы такую систему имели в виду? У меня сложилось ощущение, что нет.
13 мар 07, 14:21    [3892258]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Коллеги. Свет, наконец то, включили. Отвечу всем по-порядку...
13 мар 07, 14:45    [3892384]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

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


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

К сообщению приложен файл. Размер - 0Kb
13 мар 07, 14:53    [3892448]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
И лог контрагента. Все, что логгируется реализовано на базовом уровне.

К сообщению приложен файл. Размер - 0Kb
13 мар 07, 14:54    [3892453]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

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


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

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


В базе существует ссылочная целостность. Метаданные и данные в одной табоице не смешаны. Если посмотреть внимательно на структуру бд - классическая реляционная модель.
13 мар 07, 15:02    [3892522]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
stomsky
Member

Откуда: Волгоград
Сообщений: 158
Shurgenz
А потомка глубже 4-го уровня придумать в реальной жизни трудновато (мне по крайней мере).

Хотите подскажу? Справочник для Органа федерального казначейства:

Контрагент->Организация->Получатель_бюджетных_средств->Распрядитель_бюджетных_средств->Управление_федерального_казначейства

И это еще не предел! Хотя при такой иерархии может быть стоит подумать о другой структуре БД? Хотя с другой стороны если в поле "Получатель" платежного поручения может находиться как человек (физ.лицо), так и УФК по Волгоградской области! Т.е. наиболее разумным лично мне кажется отношение 1:М для таблиц "Контрагент" и "Платежные документы" (это я еще не расматриваю способы "размазать" по таблицам документы!).
13 мар 07, 15:07    [3892549]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Shurgenz
Насколько я успел в этой всей схеме хоть что-то понять, там именно легкая, а может и не очень легкая степень денормализации...


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

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


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

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


Вы глубоко не правы.
13 мар 07, 15:08    [3892557]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Мне из картинок совершенно непонятно, что и как сделано с логгированием.
13 мар 07, 15:09    [3892563]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить