hVosttЧестно говоря 1-1 это чаще фейл, чем вин. Должны быть достаточные основания, чтобы впендюривать 1-1, например, для повышения производительности выборок и некоторых запросов. Зачем их навешивать вдоль и поперёк только потому, что так можно? Тем более через модель наследования 1-1 получаются вообще нативно. Давай лучше рассмотрим конкретный пример из конкретной предметной области? Тут

message: сообщение
message_task: сообщение-задача
message_comments: сообщение-комментарий

Предлагай альтернативу.

hVosttAlexey2112,

Если настроек много, и они расширяемые, то наверное следует подумать о другой модели хранения, нормализовать, например, вот так:

TABLE Properties (Id, Name, Group, Type)

TABLE Values (Id, UserId, PropertyId, Value)EAV - зло!
Alexey2112Уже можно покритиковать - в атрибутах требуются захардкоденные строками имена сущностей для FK.И какие несчастья нам грозят из-за этого "ужаса"?

Alexey2112Алексей Кпропущено...
И какие несчастья нам грозят из-за этого "ужаса"?
Рефакторинг. Наделал ты сто таблиц, наделал отображений, и тут надо поменять пару названий, которые встречаются 50 раз. Полнотекстовый поиск, вместо контекстного рефакторинга?Я за кодогенерацию контекста по БД, пусть даже это DbContext API (code-first).

Но если хочется именно code-first + строгая типизация, то да - Fluent. Ничего моструозного в нём нет, благо code-complete присутствует.
Alexey2112Ещё раз, ребята. Нет какого-то определённого правила, как лучше моделить в БД композицию классов (т. е. когда поля класса могут иметь тип другого класса)? Т. е. нельзя сказать, что композиция - только через EAV, или через 1-1..0, или только через complex types? Каждый раз подбирается по ситуации?Конечно, всё всегда делается в зависимости от поставленной задачи и предпочтений.

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

hVosttАлексей К Тут

message: сообщение
message_task: сообщение-задача
message_comments: сообщение-комментарий

Предлагай альтернативу.

На мой взгляд, тупо. Можно воспользоваться наследованием и хранить всё в одной таблице, EF такое предлагает нативно. Или воспользоваться наследованием, если религия не позволяет в одной, хранить в нескольких таблицах. EF предлагает такое нативно. Вопросы? ))Смешались в кучу люди, кони... Я про таблицы в БД, связанные отношением 1-1, ненужные, как ты утверждал выше. Про способы маппинга объектов на эти таблицы с помощью EF я ни слова.
hVosttАлексей КEAV - зло!

Какой-то нелепый наброс. Зло это бездумное, фанатичное, следование какой-то одной идеологии. В данном случае EAV это то, что доктор прописал, так как гибко и не создаёт потенциальных таблиц с овер 100 полями. И не надо мне рассказывать только сказочки и глупые нелепости о том, как некто в компании Х работал там с 10000000000 таблицами с 1000000000 полями. Если ума нет, считай калека.Никогда ещё не было проблем от количества таблиц или количества полей в них. Их должно быть столько, сколько того требует предметная область. При статичной структуре данных EAV не упёрлось.
hVosttАлексей КЯ за кодогенерацию контекста по БД, пусть даже это DbContext API (code-first).

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

Кодогенерация нафиг не упала без действительно реальной в этом необходимости.Мне удобнее создавать таблицы в дизайнере, чем описывать их в тексте C#.

hVosttАлексей КНо если хочется именно code-first + строгая типизация, то да - Fluent. Ничего моструозного в нём нет, благо code-complete присутствует.

Убого. Тяжко поддерживать при разрастании БД, с определённого момента практически не поддаётся контролю. Только для для тех, у кого просто банально не хватило тямы освоить соглашения.Кодогенерация контекста по БД по сути те же соглашения, только в другую сторону.
hVosttEAV не панацея, но для многих случаев гибче на пару порядков, если не меньше, чем деревянный набор колонок в таблице.Ну мучайся, я не против. :-)

hVosttАлексей КСмешались в кучу люди, кони... Я про таблицы в БД, связанные отношением 1-1, ненужные, как ты утверждал выше. Про способы маппинга объектов на эти таблицы с помощью EF я ни слова.

Может ты прочитаешь ещё раз? Я говорил, что мапить можно как в 1:1, так и в одну таблицу. 1:1 -- это не единственное решение задачи.Ты утверждал, что 1-1 в БД зло. Разумеется, это не единственное решение, но оно имеет право на жизнь не менее, чем все остальные.
hVosttВ твоём случае профита даже муха не нарыдала, просто ХЗ пойми зачем этот мусор в БД. Ради какой великой цели, не понятно.Таки без 1-1 в БД там станет очень неудобно. Великая цель, иметь вложения одновременно у задач и комментариев, там описана. Но ты как всегда не читаешь, но осуждаешь.

hVosttАлексей КНикогда ещё не было проблем от количества таблиц или количества полей в них. Их должно быть столько, сколько того требует предметная область. При статичной структуре данных EAV не упёрлось.

Речь идёт о наборах свойств, их много, они могут группироваться. Мало ли что там ещё понадобится. EAV тут упёрлось очень даже.Это пока не начнётся использование этих свойств в прикладном коде. А сделать форму их редактирования, аля PropertyGrid, с EAV конечно удобнее, если повезёт конечно - если типы значений свойств будут одинаковыми.

hVosttДавай без EAV, дай мне на каждое свойство свой доступ для каждого пользователя, настраиваемый естественно в какой-нибудь админке. Съел? В EAV такое лепится и много чего другого проще пареной репы. Нахрена себе жизнь усложнять сразу же? Ради какой великой цели?Ну делай методы в сервисах, выдающие свойства по одному или группами, давай права на эти методы. Замути кодогенерацию, если это поможет.

hVosttАлексей КМне удобнее создавать таблицы в дизайнере, чем описывать их в тексте C#.

Просто ты работаешь один, давай начистоту.Знаю я эту печальную историю: только CRM-щики 35+ LVL работают группами, нам до них ещё далеко.

hVosttАлексей ККодогенерация контекста по БД по сути те же соглашения, только в другую сторону.

Это херня какая-то для поддержки кучки старпёров, ничего кроме дизайнера в этой жизни не осиливших Объективненько. :-)

hVosttАлексей КТаки без 1-1 в БД там станет очень неудобно. Великая цель, иметь вложения одновременно у задач и комментариев, там описана. Но ты как всегда не читаешь, но осуждаешь.

Я всё читал и когда-то даже пытался чему-то научиться разбирая твой проект )) Твоя задача легко укладывается в 1 таблицу, возможность выбрать только инфу для для задач или комментариев не теряется, но есть возможность легко получить все вложения одним запросом, не ковыряясь в схеме БД, что выяснить, да сколько ж всего их там. Легко расширяемая, без замусоривания БД лишними таблицами. Причин 1-1 не увидел ни единой, кроме, наверное, религиозной. А религиозные причины не обсуждаются ))Но это твоё мнение, не больше и не меньше. Я раньше тоже был за денормализованные таблицы с целью упрощения запросов. Теперь есть EF с ассоциациями, поэтому проблема обилия join-ов не стоит, поэтому пусть уж лучше БД будет в нормализованном виде, без избыточностей и лишних необязательных полей с хитрой логикой их обязательности.

hVosttАлексей КЭто пока не начнётся использование этих свойств в прикладном коде. А сделать форму их редактирования, аля PropertyGrid, с EAV конечно удобнее, если повезёт конечно - если типы значений свойств будут одинаковыми.
Какие проблемы использования в прикладном коде? Я одним запросом получил набор свойств, сгруппированных как надо, могу их отсортировать по какому-то признаку, могу скрыть отдельные свойства по другому признаку, по третьему признаку могу разрешить редактировать пользователю или нет.. Признаки -- это то, чего у колонок тупо нет и не будет никогда.Ну эти свойства вероятно предназначены для хранения настроек системы, которые будут участвовать в прикладной логике:


vs


Нам такого счастья не надо. А расширить существующие метаданные, живущие в syscolumns и т. п., это работы на 5 минут...

hVosttАлексей КНу делай методы в сервисах, выдающие свойства по одному или группами, давай права на эти методы. Замути кодогенерацию, если это поможет.

Чтобы замутить кодогенерацию, надо написать код. Усложнить жизнь себе и людям, которым это придётся сопровождать. Задокументировать и вносить в документацию изменения при добавлении очередного свойства. Ты любитель граблей и кактусов? Охотно верю ))Само ничего не делается, да...

hVosttАлексей КЗнаю я эту печальную историю: только CRM-щики 35+ LVL работают группами, нам до них ещё далеко.

Я к тому, что ты в рассуждениях никогда не учитываешь ни работу в команде, ни возможность сопровождения другим людям, ни прикладных программеров, которые захотят заюзать твой код, ни просто тот факт, что ты не вечен, тебе всё может надоесть, а там по твоей идеологии, хоть трава не расти. Мне-то всё равно, но принципиально я не могу согласиться с подходами, уместными только для гастрабайтера-одиночки Опять пустые слова. Приводи конкретные примеры.

hVosttАлексей КОбъективненько. :-)

Это я про любителей дизайнеров всяких. И обычно, знающих не больше одного дизайнера, ну максимум двух. Любой шаг в сторону вызывает у таких кодеров паническую реакцию. Зная это, MS замутила database first, чтобы эти люди как бы и в тренде оставались, и не отбирать у них игрушку Я не представляю, как можно делать большую и сложную БД без дизайнера. Пользуемся родным дизайнером из MSSQL Management Studio, он устраивает более чем. Сторонние дизайнеры вроде ERWin не предлагать.

Alexey2112Алексей КНо это твоё мнение, не больше и не меньше. Я раньше тоже был за денормализованные таблицы с целью упрощения запросов. Теперь есть EF с ассоциациями, поэтому проблема обилия join-ов не стоит, поэтому пусть уж лучше БД будет в нормализованном виде, без избыточностей и лишних необязательных полей с хитрой логикой их обязательности.
Но такой подход не верен в случае, когда предметная модель пока только устаканивается, постоянно добавляются-убираются-перемещаются-переименовываются свойства объектов (столбцы таблиц) и т. д. Да?

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

Alexey2112Если сделать так, то в чём могут быть трудности в краткосрочной перспективе? Ну, с учётом того, что потом мы всё переделаем (и перегоним данные со старой БД в новую, конечно), когда предметная область у нас устоится.Этого скорее всего не произойдёт. Принцип "работает да и ладно" достаточно силён.

Alexey2112Я имею ввиду, одной таблицы, вроде, вполне достаточно. Я теперь не понимаю, зачем городить связь из двух, как Хвост раньше предложил, или вообще из трёх, как в классическом EAV... А, понял. В классическом EAV формируются сущности, а у меня сущность одна (Settings), поэтому достаточно двух или вообще одной таблицы.Сущность Settings не одна, к ней в дополнение идёт некий репозитарий, отвечающий за работу с конкретными свойствами.

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

Дело ваше конечно, просто мысли вслух...

hVosttАлексей КНо это твоё мнение, не больше и не меньше. Я раньше тоже был за денормализованные таблицы с целью упрощения запросов. Теперь есть EF с ассоциациями, поэтому проблема обилия join-ов не стоит, поэтому пусть уж лучше БД будет в нормализованном виде, без избыточностей и лишних необязательных полей с хитрой логикой их обязательности.

Ты как будто в танке сидишь. Сколько тебе ещё раз сказать, что EF прекрасно работает с наследованием как разложенных в таблицах 1:1, так в одной? С точки зрения программиста разница вообще не будет заметна, но будет заметна, когда данных станет много и выбор программиста был неверен.

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

Один класс-одна таблица - это мой выбор и не тебе его осуждать. Но можешь не согласиться, твоё право.
hVosttАлексей КНам такого счастья не надо. А расширить существующие метаданные, живущие в syscolumns и т. п., это работы на 5 минут...

Т.е. для каждой колонки ты таки создашь отдельную запись метаданных в отдельной таблице? Просто офигенное решение ))))) Работы на 5 минут... Спасибо, посмеялся.Что не так?
hVosttАлексей КЯ не представляю, как можно делать большую и сложную БД без дизайнера. Пользуемся родным дизайнером из MSSQL Management Studio, он устраивает более чем. Сторонние дизайнеры вроде ERWin не предлагать.

Ты похоже просто тупо не видишь разницы между моделями предметной области, данных и схемой данных в БД. Для схемы данных дизайнер нафиг не упёрся. Дизайнер это не плохо вовсе, но код важнее .БД важнее кода.

Alexey2112Алексей Кпропущено...
БД важнее кода.
БД это и есть код. Ну, когда code first.Я уже выше говорил, что я за DbContext API, но против code-first как метода разработки.
Alexey2112T-SQL нафиг не нужен вообще - потому что я его не знаю и знать не хочу костыль.Не соглашусь. EF - это продвинутый генератор SQL, не больше и не меньше. Если нет чёткого понимания, какой будет план выполнения у сгенерированного SQL - это путь в никуда.
Alexey2112Вот если бы сразу .NET в этот SQL Server вогнать. Вот, code first - шаг навстречу этому.И изменить модель данных в MSSQL с реляционной на какую-нибудь другую?

hVosttАлексей КЯ знаю, что это можно решить наследованием, но мне больше нравится это решать ассоциациями. Я хочу работать с классами, один-в-один сопоставленными с таблицами в БД и связанными между собой ассоциациями. Тут и без таких подвыподвертов бардака в предметной области хватает, так мне ещё и разбираться, какой группе таблиц соответствует какой класс.

Где тут бардак? У меня есть Message и есть UserMessage, GroupMessage, ProjectMessage. Почему это должны быть совершенно разные таблицы, если суть у них одна, основной набор данных один, базовая логика одинаковая, основные контролы/шаблоны UI одни? С какого перепугу? Или предлагаешь это всё нагенерить? С логикой у меня всё в порядке, а у тебя? ))Ты строишь систему от ООП модели, я строю от реляционной модели в БД, вот и вся разница. Мне удобнее так, тебе удобнее по другому. Мы оба правы, доказывать тут что-то глупо, оба подхода имеют право на жизнь.
hVosttАлексей КОдин класс-одна таблица - это мой выбор и не тебе его осуждать. Но можешь не согласиться, твоё право.

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

hVosttАлексей КЧто не так?

Бардак, разброд и шатания, усложнение без видимых причин, кроме разве что небольшой степени упоротости )Спасибо за ценную информацию, которая наверняка пригодится читателям форума!

hVosttАлексей КБД важнее кода.

А крокодил зеленее ширины слона. Рубль слаще бутерброда.

Глупые сравнения меня не интересуют, и код и БД одинаково важны, т.к. юзер останется с носом, что без одного, что без другого. Или дизайнер и БД это для тебя одно и тоже? )))В работающей информационной системе обычно код модифицировать проще, чем структуру БД. Обычно код меняется чаще структуры БД. Утерянный код восстановить можно, утерянную БД восстановить невозможно.

Вероятно, ты работаешь не с информационными системами, отсюда у тебя другие взгляды на ситуацию.

hVosttАлексей КЕсли нет чёткого понимания, какой будет план выполнения у сгенерированного SQL - это путь в никуда.

И как же ты живёшь с DbContext? На все LINQ запросы планы посмотрел?На все, имеющие проблемную статистику выполнения.

hVosttАлексей КЯ знаю, что это можно решить наследованием, но мне больше нравится это решать ассоциациями. Я хочу работать с классами, один-в-один сопоставленными с таблицами в БД и связанными между собой ассоциациями. Тут и без таких подвыподвертов бардака в предметной области хватает, так мне ещё и разбираться, какой группе таблиц соответствует какой класс.

Где тут бардак? У меня есть Message и есть UserMessage, GroupMessage, ProjectMessage. Почему это должны быть совершенно разные таблицы, если суть у них одна, основной набор данных один, базовая логика одинаковая, основные контролы/шаблоны UI одни? С какого перепугу? Или предлагаешь это всё нагенерить? С логикой у меня всё в порядке, а у тебя? ))Основной набор данных один, но есть и специфичный набор данных, разный для каждого класса. Теперь включаем логику, с которой у тебя всё в порядке. :-)