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 с реляционной на какую-нибудь другую?