Отношения Many-many: использовать ассоциативную таблицу или разграниченные значения в столбце?

Это сбивает с толку разработчиков.

Найдите лучших разработчиков. Это правильный подход.

Ваше предложение - элегантное, мощное, передовое решение.

Поскольку я не думаю, что в других ответах достаточно сказано следующее, я собираюсь это сделать.

] Если ваши разработчики 1) не могут понять, как смоделировать отношение «многие ко многим» в реляционной базе данных, и 2) настойчиво настаивают на сохранении ваших CategoryID в качестве символьных данных с разделителями,

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

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

Я надеюсь, что этот ответ очень полезен для вас.

Обновление

Суть моего вопроса не в путанице разработчика, а в том, что поделать.

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

Значения с разделителями являются неправильным решением, за исключением крайне редких случаев. Когда отдельные значения когда-либо запрашиваются / вставляются / удаляются / обновляются, это доказывает, что это было неправильное решение, потому что вы должны проанализировать и коснуться всех других значений просто для работы с желаемым. Делая это, вы нарушаете первую (!!!) нормальную форму (эта фраза должна звучать для вас как невероятно мерзкая выговорка). Использование XML, чтобы сделать то же самое, тоже неправильно. Хранение значений с разделителями или XML с несколькими значениями в столбце может иметь смысл, когда он рассматривается как неделимый и непрозрачный «пакет свойств», который НЕ запрашивается базой данных, но всегда отправляется целиком другому потребителю ( возможно, веб-сервер или получатель EDI).

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

Я должен допустить, что есть некоторые довольно сложные реализации нереляционного хранения данных, использующие мешки текстовых свойств (такие как Facebook (?) И другие многомиллионные пользовательские сайты, работающие на тысячах серверов). Когда ваша база данных, пользовательская база и количество транзакций в секунду достаточно велики, вам понадобятся деньги для ее разработки. А пока придерживайтесь лучших практик.

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

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

Я должен допустить, что есть некоторые довольно сложные реализации нереляционного хранения данных, использующие мешки текстовых свойств (такие как Facebook (?) И другие многомиллионные пользовательские сайты, работающие на тысячах серверов). Когда ваша база данных, пользовательская база и количество транзакций в секунду достаточно велики, вам понадобятся деньги для ее разработки. А пока придерживайтесь лучших практик.

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

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

Я должен допустить, что есть некоторые довольно сложные реализации нереляционного хранения данных, использующие мешки текстовых свойств (такие как Facebook (?) И другие многомиллионные пользовательские сайты, работающие на тысячах серверов). Когда ваша база данных, пользовательская база и количество транзакций в секунду достаточно велики, вам понадобятся деньги для ее разработки. А пока придерживайтесь лучших практик.

Разработчики, которые думают, что нарушение первой нормальной формы - хорошая идея, являются очень неопытными разработчиками в моей книге.

Я должен допустить, что есть некоторые довольно сложные реализации нереляционного хранения данных, использующие мешки текстовых свойств (такие как Facebook (?) И другие многомиллионные пользовательские сайты, работающие на тысячах серверов). Когда ваша база данных, пользовательская база и количество транзакций в секунду достаточно велики, вам понадобятся деньги для ее разработки. А пока придерживайтесь лучших практик.

Разработчики, которые думают, что нарушение первой нормальной формы - хорошая идея, являются очень неопытными разработчиками в моей книге.

Я должен допустить, что есть некоторые довольно сложные реализации нереляционного хранения данных, использующие мешки текстовых свойств (такие как Facebook (?) И другие многомиллионные пользовательские сайты, работающие на тысячах серверов). Когда ваша база данных, пользовательская база и количество транзакций в секунду достаточно велики, вам понадобятся деньги для ее разработки. А пока придерживайтесь лучших практик.

и количество транзакций в секунду достаточно велико, и у вас будут деньги на его разработку. А пока придерживайтесь лучших практик.

и количество транзакций в секунду достаточно велико, и у вас будут деньги на его разработку. А пока придерживайтесь лучших практик.

Почти всегда большая ошибка - использовать идентификаторы, разделенные запятыми.
СУБД предназначены для хранения отношений.

Это сбивает с толку разработчиков.

Добейтесь лучших разработчиков. Это правильный подход.

--121 --- 1695469--

Я написал довольно быстрый метод на c #, который превосходит Regex. Он размещен в статье на CodeProject.

Его преимущества, среди лучшей производительности, - возможность заменить именованные и пронумерованные сущности HTML (такие как и и . ] & 203; ) и замена блоков комментариев и т. Д.

Прочтите связанную статью о CodeProject .

Спасибо.

--121 --- 2037366--

Почти всегда большая ошибка - использовать идентификаторы, разделенные запятыми.
СУБД предназначены для хранения отношений.

- 121 --- 1695471--

Отображение «многие ко многим», которое вы делаете, нормально и нормализовано. Это также позволяет добавлять другие данные позже, если это необходимо. Например, допустим, вы хотите добавить время, когда категория была добавлена ​​в документ.

Я бы посоветовал добавить суррогатный первичный ключ в таблицу document_category. И ограничение Unique (documentmentid, categoryid), если в этом есть смысл.

Почему разработчики запутались?

--121 --- 1695473--

Мое решение - создать Ассоциативная таблица выглядит следующим образом: сбивает с толку разработчиков

Правда? это база данных 101, если это их смущает, то, возможно, им нужно отойти от своего кода, сгенерированного мастером, и изучить некоторую базовую нормализацию БД.

То, что вы предлагаете, является правильным решением !!

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

Я бы посоветовал добавить суррогатный первичный ключ в таблицу document_category. И ограничение Unique (documentmentid, categoryid), если в этом есть смысл.

Почему разработчики запутались?

The 'this is confusing to the developers' design means you have under-educated developers. It is the better relational database design - you should use it if at all possible.

If you really want to use the list structure, then use a DBMS that understands them. Examples of such databases would be the U2 (Unidata, Universe) DBMS, which are (or were, once upon a long time ago) based on the Pick DBMS. There are likely to be other similar DBMS providers.

This is the classic object-relational mapping problem. The developers are probably not stupid, just inexperienced or unaccustomed to doing things the right way. Shouting "3NF!" over and over again won't convince them of the right way.

I suggest you ask your developers to explain to you how they would get a count of documents by category using the pipe-delimited approach. It would be a nightmare, whereas the link table makes it quite simple.

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

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

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

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

Да, это может быть просто лень, злой умысел или невежество, но я уверен, что большую часть времени разработчики делают это, потому что им постоянно говорят: «Просто поймите. сделано".