Много сущностей в одной таблице / Microsoft SQL Server / Sql.ru

Добро пожаловать в форум, Guest >> Войти \| Регистрация \| Поиск \| Правила \|			В избранное \| Подписаться
Все форумы / Microsoft SQL Server

Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все

Много сущностей в одной таблице [new]

design21
Member

Откуда: Minsk
Сообщений: 59

Приложение разрабатывается по принципу Code First с помощью Microsoft Entity Framework.
Столкнулся со следующей схемой базы.

CREATE TABLE [dbo].[Qualifiers](
	[QualifierId] [uniqueidentifier] PRIMARY KEY CLUSTERED,
	[QualifierType] [nvarchar](30) NULL,
	[QualifierValue] [nvarchar](256) NULL)

Таблица Qualifiers содержит данные о множестве сущностей. Например вот так:

CREATE TABLE [dbo].[MemberEmails](
	[MemberId] [uniqueidentifier] NOT NULL,
	[QualifierId] [uniqueidentifier] NOT NULL,
CONSTRAINT [PK_MemberEmails] PRIMARY KEY CLUSTERED ([MemberId],[QualifierId]))

В данном случае в таблице [dbo].[Qualifiers] будет следующие записи:
[QualifierType] = work/home
[QualifierValue] = user@company.com

Аналогичным образом таблица Qualifiers содержит данные относящиеся еще к десятку сущностей. Например:

CREATE TABLE [dbo].[MemberCommunicationNumbers](
	[MemberId] [uniqueidentifier] NOT NULL,
	[QualifierId] [uniqueidentifier] NOT NULL,
CONSTRAINT [PK_MemberCommunicationNumbers] PRIMARY KEY CLUSTERED ([MemberId], [QualifierId]))

и т.д.

Мне, как разработчику БД, такая схема не нравится. Логичнее было бы хранить данные прямо в таблице MemberEmails, а так мы получаем:

1) Линший JOIN c большой таблицей при получении Email пользователя.

 SELECT q.*
  FROM [dbo].[Qualifiers] q
  JOIN [dbo].[MemberEmails] me ON me.QualifierId=q.QualifierId
  WHERE me.MemberId = '622780DA-D570-42E2-BE21-AD0BB9F6E6AD'

вроде clustered index seek, но все равно неприятно.

2) При вставке данных происходит лишняя операция INSERT в [dbo].[Qualifiers] (поддержка кластерного индекса в большой таблице)

3) При UPDATE опять же лишний JOIN.

Стоит ли убеждать заказчика перестроить схему базы? Помогите привести весомые аргументы.

22 дек 12, 17:36 [13671093] Ответить | Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]

alexeyvg
Member

Откуда: Moscow
Сообщений: 31779

design21
[QualifierId] [uniqueidentifier] PRIMARY KEY CLUSTERED,

Ого, круто!!!

Зачем так сделано, да ещё и во всех таблицах?

design21
Мне, как разработчику БД, такая схема не нравится

Мне кажется, это не должно нравиться любому разработчику, не только БД. Совершенно глупейшая схема.

Там что, всё так сделано? Любые, абсолютно любые аттрибуты сущностей хранят значения через ссылку на некую странную таблицу значений? Разумеется, с потерей как минимум контроля типов, с огромными ограничениями и т.п. ?

design21
Стоит ли убеждать заказчика перестроить схему базы? Помогите привести весомые аргументы.

Понятно, что стоит.

Главное, нужно убеждать заказчика сменить проектировщиков БД. Если вы даже уломаете заказчика на изменения, всё равно эти горе-специалисты будут вам и проекту вредить, и добьются своего.

Аргументы... Ну как минимум кластерный индекс на гуид без достаточных оснований.
Ещё на уровень проектировщика указывает NULL для QualifierType и QualifierValue. Что он этим хотел сказать?

По самой схеме аргумент - непонятность модели данных, её соответствие бизнес-модели.

Модель данных предполагает (то есть явно указывает на ...), что один Qualifier (в смысле, одна запись в таблице) используется у многих записей для разных сущностей. Это так и есть, кто и как будет управлять экземплярами Qualifier? Для этого предусмотрены отдельные интерфейсы, формы, отчёты? Если значения Qualifier - отдельная самостоятельная сущность, какое предполагается управление?

design21
3) При UPDATE опять же лишний JOIN.

При UPDATE не просто лишний JOIN, всё намного, намного сложнее. По причинам, указанным выше, при изменениях email нужно либо менять его для всех, либо делать только INSERT, либо проводить поиск значения во всех таблицах.

22 дек 12, 19:28 [13671327] Ответить | Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]
design21 Member Откуда: Minsk Сообщений: 59	Эта схема, как я понимаю, была создана автоматически: кодогенератом LINQ. Сменить подход навряд ли получится. Работа с базой скрыта от .NET разработчиков и несоответствие схемы базы - бизнес-модели, может не оказаться достаточно весомым аргументом. Возможно со стороны .NET кода все соответствует бизнесу. Хотя я этот аргумент тоже приведу, спасибо. На отсутствие контроля типов мне вероятно тоже скажут, что все проверки вынесены на "application level". Пока у меня получился вот такой список аргументов в пользу отказа от схемы с Qualifiers 1 Отсутствие возможности использовать Foreign KEY 2 Необходимость все данные приводить к [nvarchar](256) - нету контроля типов 3 Быстрая фрагментация индекса, в связи с тем что он общий для нескольких сущностей. 4 Дополнительные операции вставки. 5 Дополнительные операции соединения с таблицей Qualifiers. 6 Несоответствие схемы базы бизнес-модели Может есть еще какие-то мысли? Замена кластерного индекса на не кластерный - это скорее тюнинг производительности. В начале упор мне кажется делать на это не нужно.
24 дек 12, 21:25 [13679640] Ответить \| Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]
invm Member Откуда: Москва Сообщений: 9633	design21, Все ваши аргументы у большинства ОРМ-щиков просто вызовут идиосинкразию. Так что не думаю, что у вас получится их переубедить.
24 дек 12, 22:04 [13679763] Ответить \| Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]

alexeyvg
Member

Откуда: Moscow
Сообщений: 31779

design21
Эта схема, как я понимаю, была создана автоматически: кодогенератом LINQ. Сменить подход навряд ли получится.

Я вообще не программировал на LINQ, но я сомневаюсь, что он сам делает модели данных, ему взять то её неоткуда.

design21
Мне, как разработчику БД, такая схема не нравится

Либо вы (разработчик БД) делаете модель БД, либо её делает линк, веб-программист, уборщица и т.д.

Какие собственно варианты? Вы же не можете разрабатывать и отвечать за то, что делает LINQ? :-)

25 дек 12, 00:16 [13680209] Ответить | Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]

alexeyvg
Member

Откуда: Moscow
Сообщений: 31779

invm
design21, Все ваши аргументы у большинства ОРМ-щиков просто вызовут идиосинкразию. Так что не думаю, что у вас получится их переубедить.

Я думаю, пп 2 и 6 могут как то понять...

25 дек 12, 00:24 [13680234] Ответить | Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]

AnaceH
Member

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

design21,

Судя по схеме БД там в классах беда горемычная.

автор
Возможно со стороны .NET кода все соответствует бизнесу.

Очень маловероятно. Code First EF зеркалит классы напрямую в таблицы. Единственное, что EF сделал "самовольно" - кластерный индекс на гуиде. Возможно это можно как-то поменять, особо в Code First не вникал, но если и можно, дотнетчики шлепнули по дефолту. Остальное, а конкретно новаторский подход к хранению атрибутов сущности\класса - дело рук ваших сотрудников, к гадалке не ходи. Что делать в такой ситуации? Гнать в шею таких новаторов. Все остальное - полумеры.

25 дек 12, 00:46 [13680294] Ответить | Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]
MasterZiv Member Откуда: Питер Сообщений: 34657	[quot design21] Мне, как разработчику БД, такая схема не нравится. Чем не нравится ? Либо говори, либо уж и не заикайся... Логичнее было бы хранить данные прямо в таблице MemberEmails, а так мы получаем: Ну как бы тут 0) этих атрибутов может быть много (одного типа) в отличие от единичного поля в таблице. 1) такая схема позволяет также находу добавлять новые атрибуты новых типов. 1) Линший JOIN c большой таблицей при получении Email пользователя. Лишний JOIN вообще не проблема. Как аргумент не катит. 2) При вставке данных происходит лишняя операция INSERT в [dbo].[Qualifiers] (поддержка кластерного индекса в большой таблице) Реально только UID в качестве кластерных ключей немного настораживает. Но вроде бы не особенно и плохо. O(logN), не катит аргумент. 3) При UPDATE опять же лишний JOIN. Не катит. Зато если надо менять атрибут, он только в дочерней таблице меняться будет. Стоит ли убеждать заказчика перестроить схему базы? Стоит сначала понять, чем тебе это не нравится. Помогите привести весомые аргументы Подозреваю, что их и нет, аргументов-то ... Кроме может быть "сложности постижения структуры БД".
25 дек 12, 01:37 [13680387] Ответить \| Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]
MasterZiv Member Откуда: Питер Сообщений: 34657	Там что, всё так сделано? Любые, абсолютно любые аттрибуты сущностей хранят значения через ссылку на некую странную таблицу значений? Разумеется, с потерей как минимум контроля типов, с огромными ограничениями и т.п. ? Не факт. Нам предъявили только таблицу одного типа. Никто не знает кроме ТС есть там другие таблицы или нет.
25 дек 12, 01:40 [13680392] Ответить \| Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]

alexeyvg
Member

Откуда: Moscow
Сообщений: 31779

MasterZiv
Ну как бы тут 0) этих атрибутов может быть много (одного типа) в отличие от единичного поля в таблице. 1) такая схема позволяет также находу добавлять новые атрибуты новых типов.

ИМХО вы не изучили представленную схему.

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

MasterZiv
Реально только UID в качестве кластерных ключей немного настораживает. Но вроде бы не особенно и плохо. O(logN), не катит аргумент.

Нету никакого O(logN). Это было бы, если бы индекс был некластерным.

В данном случае снижение производительности при вставке данных будет уж минимум раз в 10, но это ооочень оптимистично.

MasterZiv
Зато если надо менять атрибут, он только в дочерней таблице меняться будет.

Нету тут одной дочерней таблицы.

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

25 дек 12, 09:16 [13680694] Ответить | Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]

Мистер Хенки
Member

Откуда: канализация
Сообщений: 6615

design21,

автор
была создана автоматически: кодогенератом LINQ.

этот аргумент самый весомый у противоположной стороны. Типа мы пару кнопок тынц тынц, а у нас уже практически готовое приложение. Тяжело будет его опровергнуть перед биг боссом. А так бред конечно. Qualifiers разрастется дико на продакшене и с ним нелехко будет работать. Зато интересный опыт получится.

25 дек 12, 09:46 [13680768] Ответить | Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]
super-code Member Откуда: Сообщений: 244	design21, я бы вообще увольнял сразу тех, кто использует Code First. Этот человек может думать, что у меняет проектировать БД в ms sql, но не знать даже какие типы он поддерживает и т.д.
25 дек 12, 10:16 [13680930] Ответить \| Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]

invm
Member

Откуда: Москва
Сообщений: 9633

alexeyvg

invm
design21, Все ваши аргументы у большинства ОРМ-щиков просто вызовут идиосинкразию. Так что не думаю, что у вас получится их переубедить.

Я думаю, пп 2 и 6 могут как то понять...

Как показывает практика, по причине, озвученной Мистер Хенки:

Мистер Хенки
Типа мы пару кнопок тынц тынц, а у нас уже практически готовое приложение

Ничего они понимать не захотят.

25 дек 12, 10:55 [13681180] Ответить | Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]

alexeyvg
Member

Откуда: Moscow
Сообщений: 31779

Мистер Хенки
этот аргумент самый весомый у противоположной стороны. Типа мы пару кнопок тынц тынц, а у нас уже практически готовое приложение.

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

25 дек 12, 11:23 [13681311] Ответить | Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]

MasterZiv
Member

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

Мистер Хенки

design21,

автор
была создана автоматически: кодогенератом LINQ.

Пусть растет, Не страшно.

25 дек 12, 11:23 [13681312] Ответить | Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]

alexeyvg
Member

Откуда: Moscow
Сообщений: 31779

alexeyvg

Мистер Хенки
этот аргумент самый весомый у противоположной стороны. Типа мы пару кнопок тынц тынц, а у нас уже практически готовое приложение.

Ведь объектная модель приложения наверное как то должна отражать бизнес-логику, правильно? Ну вот что это за класс такой получился, Qualifiers? Что он отражает???

25 дек 12, 11:24 [13681314] Ответить | Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]

MasterZiv
Member

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

alexeyvg

MasterZiv
Ну как бы тут 0) этих атрибутов может быть много (одного типа) в отличие от единичного поля в таблице. 1) такая схема позволяет также находу добавлять новые атрибуты новых типов.

ИМХО вы не изучили представленную схему.

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

Возможно. Посмотрю.

MasterZiv
Реально только UID в качестве кластерных ключей немного настораживает. Но вроде бы не особенно и плохом. O(logN), не катит аргумент.

Нету никакого O(logN). Это было бы, если бы индекс был некластерным.

Это все равно.

В данном случае снижение производительности при вставке данных будет уж минимум раз в 10, но это ооочень оптимистично.

Это не так.
Затраты только на хранение более длинного uid вместо integer.

MasterZiv
Зато если надо менять атрибут, он только в дочерней таблице меняться будет.

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

25 дек 12, 11:30 [13681333] Ответить | Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]

alexeyvg
Member

Откуда: Moscow
Сообщений: 31779

MasterZiv

Мистер Хенки

design21,
пропущено...

этот аргумент самый весомый у противоположной стороны. Типа мы пару кнопок тынц тынц, а у нас уже практически готовое приложение. Тяжело будет его опровергнуть перед биг боссом. А так бред конечно. Qualifiers разрастется дико на продакшене и с ним нелехко будет работать. Зато интересный опыт получится.

Пусть растет, Не страшно.

Растёт - конечно не страшно, в принципе как аргумент это приводить и не нужно.

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

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

25 дек 12, 11:33 [13681347] Ответить | Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]

alexeyvg
Member

Откуда: Moscow
Сообщений: 31779

MasterZiv
Нет, это безусловно переход от прямой реляционной модели к мета модели.

Неправильно, это не EAV и не метамодель.

Вы всё таки посмотрите схему.

25 дек 12, 11:34 [13681354] Ответить | Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]
MasterZiv Member Откуда: Питер Сообщений: 34657	Я вообще к чему. Тут проблема не просто в структуре бд. Тут еще есть шаг от простого прямолинейного проектирования в метапрограммирование. Это даже не бд проблема, а общей архитектуры системы. Топик стартер явно этим аспектом проблемы не озадачен пока, он смотрит только на бд.
25 дек 12, 11:37 [13681369] Ответить \| Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]

alexeyvg
Member

Откуда: Moscow
Сообщений: 31779

MasterZiv

Я вообще к чему.

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

ТС видит, что они испоьзуют не обычные атрибуты, и не модель EAV, которую вы называете "метапрограммированием", а непонятный бред.

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

Это просто дикая смесь из, как вы называете, "простого прямолинейного проектирования и метапрограммирования"

ИМХО, проектировщики просто замапили поля в интерфейсе на классы, а классы сами собой преобразовались в таблицы БД.

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

25 дек 12, 11:45 [13681453] Ответить | Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]
Crimean Member Откуда: Сообщений: 13148	если это не HiLoad система - забить и умеренно запастись железом если (внезапно) таки HiLoad - выкинуть Entity Framework, пока не поздно, ибо не взлетит имхо, конечно же а так - покрывающими индексами постепенно подопрете, при низком уровне модификаций в течении суток данные не будут успевать фатально фрагментироваться, а там перестроите "больные" индексы и все ок будет
25 дек 12, 12:28 [13681855] Ответить \| Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]
ЕвгенийВ Member Откуда: Москва Сообщений: 4962	design21, Есть подозрение, что через Code First сделали нечто типа пользовательских справочников. Если нужно просто показать заказчику, подписать акты, получить деньги - вполне сойдет. Иначе выкинуть на помойку и переписать.
25 дек 12, 16:06 [13684068] Ответить \| Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]

ЕвгенийВ
Member

Откуда: Москва
Сообщений: 4962

alexeyvg
Я вообще не программировал на LINQ, но я сомневаюсь, что он сам делает модели данных, ему взять то её неоткуда.

EF может такое. Она берет все это из описаний сущностей и связей между ними. А тут видимо замешены большие любители всяческих репозиториев и методов GetXXXXXById, начитавшиеся научно-популярной литературы. Штурмуют своими императивными штыками амбразуры множеств...

25 дек 12, 16:13 [13684144] Ответить | Цитировать Сообщить модератору

Re: Много сущностей в одной таблице [new]

alexeyvg
Member

Откуда: Moscow
Сообщений: 31779

Crimean
если это не HiLoad система - забить и умеренно запастись железом если (внезапно) таки HiLoad - выкинуть Entity Framework, пока не поздно, ибо не взлетит

Да дело не в нагрузке, вряд ли это будет проблемой.

Это просто из категории прог, работающих на компе у прогера. Оно перекособочится уже на этапе внедрения; я даже не говорю про то, что будет, когда сменятся пара поколений программистов, работающих с этой системой (а это щас быстро происходит, "по 10 лет на одном заводе" сейчас не работают).

ЕвгенийВ

alexeyvg
Я вообще не программировал на LINQ, но я сомневаюсь, что он сам делает модели данных, ему взять то её неоткуда.

Я имел в виду модель данных вообще, т.е. её по любому создаёт человек - либо в виде классов, либо в виде таблиц, либо рисует в аксессе - но всегда человек, а не "язык программирования" или "библиотека" самостоятельно.

Т.е. в данном случае модель данных - это "описания сущностей и связей между ними" в EF.

25 дек 12, 18:04 [13684952] Ответить | Цитировать Сообщить модератору

Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все

Все форумы / Microsoft SQL Server

Ссылка на сообщение

Ссылка (включая название темы)

Ссылка (URL)