Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
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] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31779 |
Зачем так сделано, да ещё и во всех таблицах?
Там что, всё так сделано? Любые, абсолютно любые аттрибуты сущностей хранят значения через ссылку на некую странную таблицу значений? Разумеется, с потерей как минимум контроля типов, с огромными ограничениями и т.п. ?
Главное, нужно убеждать заказчика сменить проектировщиков БД. Если вы даже уломаете заказчика на изменения, всё равно эти горе-специалисты будут вам и проекту вредить, и добьются своего. Аргументы... Ну как минимум кластерный индекс на гуид без достаточных оснований. Ещё на уровень проектировщика указывает NULL для QualifierType и QualifierValue. Что он этим хотел сказать? По самой схеме аргумент - непонятность модели данных, её соответствие бизнес-модели. Модель данных предполагает (то есть явно указывает на ...), что один Qualifier (в смысле, одна запись в таблице) используется у многих записей для разных сущностей. Это так и есть, кто и как будет управлять экземплярами Qualifier? Для этого предусмотрены отдельные интерфейсы, формы, отчёты? Если значения Qualifier - отдельная самостоятельная сущность, какое предполагается управление?
|
||||||||
22 дек 12, 19:28 [13671327] Ответить | Цитировать Сообщить модератору |
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] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9633 |
design21, Все ваши аргументы у большинства ОРМ-щиков просто вызовут идиосинкразию. Так что не думаю, что у вас получится их переубедить. |
24 дек 12, 22:04 [13679763] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31779 |
Какие собственно варианты? Вы же не можете разрабатывать и отвечать за то, что делает LINQ? :-) |
||||
25 дек 12, 00:16 [13680209] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31779 |
|
||
25 дек 12, 00:24 [13680234] Ответить | Цитировать Сообщить модератору |
AnaceH Member Откуда: Сообщений: 109 |
design21, Судя по схеме БД там в классах беда горемычная.
Очень маловероятно. Code First EF зеркалит классы напрямую в таблицы. Единственное, что EF сделал "самовольно" - кластерный индекс на гуиде. Возможно это можно как-то поменять, особо в Code First не вникал, но если и можно, дотнетчики шлепнули по дефолту. Остальное, а конкретно новаторский подход к хранению атрибутов сущности\класса - дело рук ваших сотрудников, к гадалке не ходи. Что делать в такой ситуации? Гнать в шею таких новаторов. Все остальное - полумеры. |
||
25 дек 12, 00:46 [13680294] Ответить | Цитировать Сообщить модератору |
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] Ответить | Цитировать Сообщить модератору |
MasterZiv Member Откуда: Питер Сообщений: 34657 |
Там что, всё так сделано? Любые, абсолютно любые аттрибуты сущностей хранят значения через ссылку на некую странную таблицу значений? Разумеется, с потерей как минимум контроля типов, с огромными ограничениями и т.п. ? Не факт. Нам предъявили только таблицу одного типа. Никто не знает кроме ТС есть там другие таблицы или нет. |
25 дек 12, 01:40 [13680392] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31779 |
В этой схеме может быть только один атрибут и добавить ничего нельзя (не добавляя полей в таблицу).
В данном случае снижение производительности при вставке данных будет уж минимум раз в 10, но это ооочень оптимистично.
Вы похоже считаете эту схему обычным выносом атрибута в другую таблицу, типа: вместо хранения emeil делаем таблицу с emeil и ссылку на запись в ней. А тут это не так, схема абсолютно другая. |
||||||
25 дек 12, 09:16 [13680694] Ответить | Цитировать Сообщить модератору |
Мистер Хенки Member Откуда: канализация Сообщений: 6615 |
design21,
этот аргумент самый весомый у противоположной стороны. Типа мы пару кнопок тынц тынц, а у нас уже практически готовое приложение. Тяжело будет его опровергнуть перед биг боссом. А так бред конечно. Qualifiers разрастется дико на продакшене и с ним нелехко будет работать. Зато интересный опыт получится. |
||
25 дек 12, 09:46 [13680768] Ответить | Цитировать Сообщить модератору |
super-code Member Откуда: Сообщений: 244 |
design21, я бы вообще увольнял сразу тех, кто использует Code First. Этот человек может думать, что у меняет проектировать БД в ms sql, но не знать даже какие типы он поддерживает и т.д. |
25 дек 12, 10:16 [13680930] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9633 |
|
||||||
25 дек 12, 10:55 [13681180] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31779 |
|
||
25 дек 12, 11:23 [13681311] Ответить | Цитировать Сообщить модератору |
MasterZiv Member Откуда: Питер Сообщений: 34657 |
Пусть растет, Не страшно. |
||||
25 дек 12, 11:23 [13681312] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31779 |
|
||||
25 дек 12, 11:24 [13681314] Ответить | Цитировать Сообщить модератору |
MasterZiv Member Откуда: Питер Сообщений: 34657 |
Нет, это безусловно переход от прямой реляционной модели к мета модели. |
||||||||
25 дек 12, 11:30 [13681333] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31779 |
Трудно сказать, какой аргумент можно использовать... Понятно, что для самих этих программеров никакой, они и думать не будут о какой то ерунде: типа, не опаздывают, не прогуливают, по клаве стучат - какие вообе к ним могут быть претензии??? Единственный путь - пытаться их убрать или дать им какого то наставника. Соответственно, нужно искать аргументы для боссов, которые не программеры. Тут аргументы скорее из области "кому он доверяет больше". |
||||
25 дек 12, 11:33 [13681347] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31779 |
Вы всё таки посмотрите схему. |
||
25 дек 12, 11:34 [13681354] Ответить | Цитировать Сообщить модератору |
MasterZiv Member Откуда: Питер Сообщений: 34657 |
Я вообще к чему. Тут проблема не просто в структуре бд. Тут еще есть шаг от простого прямолинейного проектирования в метапрограммирование. Это даже не бд проблема, а общей архитектуры системы. Топик стартер явно этим аспектом проблемы не озадачен пока, он смотрит только на бд. |
25 дек 12, 11:37 [13681369] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31779 |
То есть там прописаны жёсткие атрибуты, типа поле "почтовый адрес", так что для добавления другого атрибута нужно добавить новое поле или даже таблицу, но при этом из всех таблиц с жёстким атрибутом есть ссылка на общую таблицу значений. Это просто дикая смесь из, как вы называете, "простого прямолинейного проектирования и метапрограммирования" ИМХО, проектировщики просто замапили поля в интерфейсе на классы, а классы сами собой преобразовались в таблицы БД. Скажут им переименовать поле или добавить новое, пяток таблиц исчезнет, пяток новый добавится, ну а существующие данные для программиста вообще не важны :-) |
||
25 дек 12, 11:45 [13681453] Ответить | Цитировать Сообщить модератору |
Crimean Member Откуда: Сообщений: 13148 |
если это не HiLoad система - забить и умеренно запастись железом если (внезапно) таки HiLoad - выкинуть Entity Framework, пока не поздно, ибо не взлетит имхо, конечно же а так - покрывающими индексами постепенно подопрете, при низком уровне модификаций в течении суток данные не будут успевать фатально фрагментироваться, а там перестроите "больные" индексы и все ок будет |
25 дек 12, 12:28 [13681855] Ответить | Цитировать Сообщить модератору |
ЕвгенийВ Member Откуда: Москва Сообщений: 4962 |
design21, Есть подозрение, что через Code First сделали нечто типа пользовательских справочников. Если нужно просто показать заказчику, подписать акты, получить деньги - вполне сойдет. Иначе выкинуть на помойку и переписать. |
25 дек 12, 16:06 [13684068] Ответить | Цитировать Сообщить модератору |
ЕвгенийВ Member Откуда: Москва Сообщений: 4962 |
EF может такое. Она берет все это из описаний сущностей и связей между ними. А тут видимо замешены большие любители всяческих репозиториев и методов GetXXXXXById, начитавшиеся научно-популярной литературы. Штурмуют своими императивными штыками амбразуры множеств... |
||
25 дек 12, 16:13 [13684144] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31779 |
Это просто из категории прог, работающих на компе у прогера. Оно перекособочится уже на этапе внедрения; я даже не говорю про то, что будет, когда сменятся пара поколений программистов, работающих с этой системой (а это щас быстро происходит, "по 10 лет на одном заводе" сейчас не работают).
Т.е. в данном случае модель данных - это "описания сущностей и связей между ними" в EF. |
||||||
25 дек 12, 18:04 [13684952] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |