Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Архитектура: корневой справочник большого проекта  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 21763
Всем доброе время суток. Вопрос по архитектуре.
Создаю новый проект, есть одна идея, не знаю, насколько она адекватная.

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

У каждой такой таблицы есть несколько совершенно типичных полей: инкрементный ID, принадлежность определенной организации, признак "системный", признак "удален", создатель, последний редактор, дата создания, дата последнего редактирования.

Что если не плодить весь этот набор полей каждый раз в каждой таблице, не создавать со всех них констрейнты и т.п., а сделать единую корневую таблицу с этими полями, а все остальные таблицы делать к ней с ключом 1:1?

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


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

По нагрузке предполагаю в пике несколько десятков запросов в секунду, из них добавление новых записей в эту таблицу - максимум несколько в секунду. Общее количество записей в корневой таблице в перспективе может измеряться миллионами/десятками миллионов.
16 ноя 14, 19:12    [16854693]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура: корневой справочник большого проекта  [new]
vova ivanov
Member [заблокирован]

Откуда:
Сообщений: 1090
Shocker.Pro
Что если не плодить весь этот набор полей каждый раз в каждой таблице, не создавать со всех них констрейнты и т.п., а сделать единую корневую таблицу с этими полями, а все остальные таблицы делать к ней с ключом 1:1?
в 1С так, кстате, и сделано
16 ноя 14, 19:37    [16854743]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура: корневой справочник большого проекта  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
Shocker.Pro
В качестве достоинств (помимо отсутствия повторяющихся полей и констрейнтов) вижу возможность универсально ссылаться на объект из других объектов (независимо от его типа), к примеру сделать несколько ссылок на внутренние документы в сообщении внутренней переписки сотрудников или системном уведомлении, централизованное логирование некоторых полей (опять же универсальной ссылкой на документ) и т.п.
Вы же не заменяете множество таблиц на одну, вы выделяете общую таблицу для общих атрибутов.

Так что никаких из описанных вами преимуществ не наблюдается, типа "не создавать для них констрейны" (кроме сквозного ИД), а наблюдается усложнение, потому что вместо одной таблицы справочника в каждом случае придётся использовать две.
А сквозной ИД можно сделать и другими способами, если уж он вам так нравится.
16 ноя 14, 19:42    [16854770]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура: корневой справочник большого проекта  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
Shocker.Pro,

получите геморрой блокировок и неожиданные тормоза. Смысла нет разделять информацию, если это не приводит к уменьшению её хранимого объёма.
17 ноя 14, 11:21    [16857151]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура: корневой справочник большого проекта  [new]
Taffy
Member

Откуда:
Сообщений: 20501
а я вижу минус в наличии полей "последний редактор, дата последнего редактирования."

Иметь единый каталог кодов документов и справочников - очень удобно
Но это будет узкая и очень длинная таблица.
Поэтому сведения о редактировании записи лучше хранить не в "корне"
17 ноя 14, 11:35    [16857271]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура: корневой справочник большого проекта  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 21763
alexeyvg
преимуществ не наблюдается, типа "не создавать для них констрейны"
как минимум три на каждую таблицу из моего примера: "принадлежность определенной организации, создатель, последний редактор". В итоге к таблице с пользователями потянутся сотни констрейнтов - это чем-нить чревато?

alexeyvg
а наблюдается усложнение, потому что вместо одной таблицы справочника в каждом случае придётся использовать две
усложнение запроса - да, но это просто inner join, вопрос больше в том, просядет ли производительность при выборке, в обеих таблицах кластерный индекс на PK

alexeyvg
А сквозной ИД можно сделать и другими способами, если уж он вам так нравится.
Именно ИД, то есть ключевое поле? А чем тогда это будет отличаться от моего решения?

Сквозной ИД - одна из причин, вторая - убрать повторяющийся набор полей из десятков таблиц, мнение на этот счет я также услышал:
Владислав Колосов
Смысла нет разделять информацию, если это не приводит к уменьшению её хранимого объёма.


Taffy
Но это будет узкая и очень длинная таблица.
Поэтому сведения о редактировании записи лучше хранить не в "корне"
тогда отпадает смысл затеи.
А почему "лучше"? То есть, я как раз и пытаюсь выяснить, чем чревато.
17 ноя 14, 14:17    [16858690]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура: корневой справочник большого проекта  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
Shocker.Pro
alexeyvg
А сквозной ИД можно сделать и другими способами, если уж он вам так нравится.
Именно ИД, то есть ключевое поле? А чем тогда это будет отличаться от моего решения?
Отличаться будет тем, что у каждой таблицы будет своё поле ИД.
Shocker.Pro
alexeyvg
преимуществ не наблюдается, типа "не создавать для них констрейны"
как минимум три на каждую таблицу из моего примера: "принадлежность определенной организации, создатель, последний редактор". В итоге к таблице с пользователями потянутся сотни констрейнтов - это чем-нить чревато?

alexeyvg
а наблюдается усложнение, потому что вместо одной таблицы справочника в каждом случае придётся использовать две
усложнение запроса - да, но это просто inner join, вопрос больше в том, просядет ли производительность при выборке, в обеих таблицах кластерный индекс на PK
Сотни констрейнов - это чревато только замедлением удаления пользователя, чего собственно вообще не должно быть.

А увеличение количества джойнов чревато замедлением выборок, всех.
Shocker.Pro
вторая - убрать повторяющийся набор полей из десятков таблиц, мнение на этот счет я также услышал:
Владислав Колосов
Смысла нет разделять информацию, если это не приводит к уменьшению её хранимого объёма
Вот и я не понимаю, чем плох повторяющийся набор полей.

Это всё равно что уменьшать количество методов в классе, что бы не плодить использование локальных переменных внутри этих методов.
Или вот во всех классах .NET есть метод ToString(). Никто же не предлагает уменьшить число классов, что бы было поменьше этого повторяющегося метода :-)
17 ноя 14, 15:00    [16859132]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура: корневой справочник большого проекта  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 21763
alexeyvg
Отличаться будет тем, что у каждой таблицы будет своё поле ИД.
Ну тогда да - побочная таблица со своим ИД, неконстрейнтной ссылкой на ИД документа и типом документа... но это уже другая опера.

alexeyvg
Вот и я не понимаю, чем плох повторяющийся набор полей.
В голове срабатывает ООП-ный подход - если что-то повторяющееся, надо вынести в базовый класс

Проще расширять и модифицировать стандартный набор полей, пакетно обрабатывать... но, видимо, эти преимущества не перевешивают недостатков.


В общем, спасибо всем, я понял, что эта мысль не очень хорошая.
17 ноя 14, 15:13    [16859265]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура: корневой справочник большого проекта  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
Напомню, что суть нормализации в реляционной теории состоит в разделении данных таким образом, чтобы наборы не содержали избыточной информации. Если колонки вынести вместе, то получим лишнюю информацию - первичный и внешние ключи. А это против законов природы. ;-)
При конструировании базы следует стремиться отсекать данные до тех пор, пока нечего будет отсекать без нарушения требований.
17 ноя 14, 15:18    [16859318]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура: корневой справочник большого проекта  [new]
Taffy
Member

Откуда:
Сообщений: 20501
Владислав Колосов
При конструировании базы следует стремиться отсекать данные до тех пор, пока нечего будет отсекать без нарушения требований.


Это как?
Как в том анекдоте - "Во-во, по самые уши?"
17 ноя 14, 15:35    [16859541]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура: корневой справочник большого проекта  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
Taffy,

как Роден
17 ноя 14, 15:39    [16859602]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура: корневой справочник большого проекта  [new]
msLex
Member

Откуда:
Сообщений: 8192
alexeyvg
Или вот во всех классах .NET есть метод ToString().

Не самый удачный пример, ИМХО. ToString() описан как раз у базового класса Object, который соответствует универсальному справочнику и только при необходимости заменяется у дочерних классов.

Вообще вся эта тема с "универсальным справочником" несколько раз уже всплывала в контексте обсуждения реализации ООП в SQL.
17 ноя 14, 15:41    [16859622]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура: корневой справочник большого проекта  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
Выделение метода как раз противоречит решению объединить похожие данные в одну таблицу.
Выделение метода эквивалентно выделению справочника (общей информации) из таблиц. В данном случае информация полностью разнородна.
17 ноя 14, 15:44    [16859648]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура: корневой справочник большого проекта  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
Taffy
а я вижу минус в наличии полей "последний редактор, дата последнего редактирования."

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


Правильное примечание.
Еще одну таблицу прицепить 1:1
17 ноя 14, 16:12    [16859937]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура: корневой справочник большого проекта  [new]
Shovgenyuk
Member

Откуда: Ивано-Франковск-Киев
Сообщений: 462
Shocker.Pro

Что если не плодить весь этот набор полей каждый раз в каждой таблице, не создавать со всех них констрейнты и т.п., а сделать единую корневую таблицу с этими полями, а все остальные таблицы делать к ней с ключом 1:1?


Однажды я такое сделал, только не для справочникоа, а для документов.
Не то что бы очень плохо от этого, но и хорошего мало.
Не стоит, не делайте.
17 ноя 14, 17:17    [16860575]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура: корневой справочник большого проекта  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
Shocker.Pro
alexeyvg
Отличаться будет тем, что у каждой таблицы будет своё поле ИД.
Ну тогда да - побочная таблица со своим ИД, неконстрейнтной ссылкой на ИД документа и типом документа... но это уже другая опера.
Какая ещё побочная таблица???
Нужно вам сделать три таблицы, делаете три таблицы, у каждой свой ИД, делите их на диапазоны, получаете уникальный по всей базе ИД.
Shocker.Pro
alexeyvg
Вот и я не понимаю, чем плох повторяющийся набор полей.
В голове срабатывает ООП-ный подход - если что-то повторяющееся, надо вынести в базовый класс

msLex
alexeyvg
Или вот во всех классах .NET есть метод ToString().

Не самый удачный пример, ИМХО. ToString() описан как раз у базового класса Object, который соответствует универсальному справочнику и только при необходимости заменяется у дочерних классов.
Ну, наследование в ООП - это всего лишь синтаксическое удобство.

Если у вас в родительском классе есть свойство, вы же не создаёте в объектах дочернего класса ссылку на дополнительный объект родительского класса в памяти, в котором уже будет это свойство? При создании объекта дочернего класса у него будет это унаследованное свойство прямо внутри.

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

Ещё нужно учитывать, что всё таки поля в таблицах, даже если они являются PK и FK, это не адреса и ссылки на объекты, а атрибуты записей, и отношения таблиц - это результат поиска в запросах и результат выполнения операций реляционной алгебры.
То есть нечто более ресурсоёмкое и концептуально сложное, чем ссылка на вложенный объект.
Поэтому такие отношения не нужно сувать куда попало.
17 ноя 14, 18:44    [16861333]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура: корневой справочник большого проекта  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
Shovgenyuk
Shocker.Pro
Что если не плодить весь этот набор полей каждый раз в каждой таблице, не создавать со всех них констрейнты и т.п., а сделать единую корневую таблицу с этими полями, а все остальные таблицы делать к ней с ключом 1:1?


Однажды я такое сделал, только не для справочникоа, а для документов.
Не то что бы очень плохо от этого, но и хорошего мало.
Не стоит, не делайте.
Я такое делал в некоторых проектах, когда то давно.

В принципе, нормальный архитектурный приём, как и все остальные. Но нужно его применять с совершенно чёткими целями, с просчитываемыми выгодами в конкретной системе!

Например, система, в которой 99.9% запросов на получение данных будет требовать именно только несколько общих атрибутов, и только оставшаяся десятая доля процента - полной записи.
Вот буквально - все без исключения многочисленные запросы, получающие данные списками, получают их с общими атрибутами. И только в запросе получения клиентом записи по ИД получается полная запись.
Тогда да, такой подход я назову оправданным.
17 ноя 14, 18:50    [16861360]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить