Между двумя таблицами связь один ко многим. Пусть будет "Работа" и "Договор". Договор содержит идентификатор работы (ключ реализован строкой символов).
Естественно, быстро выяснилось, что к одному договору может принадлежать несколько работ.
И теперь программист предлагает хранить в таблице "Договор" не один строковый идентификатор работы, а строку с множеством идентификаторов работы разделяемых спец символом "@". Дальше в запросах он это фильтровать собирается.
Я с теорией баз данных знаком отдаленно, т.к. это не моя специальность. Но такие методы проектирования вызывают недоумение.
Ладно строковые поля в качестве ключа, но такой способ организации отношения один ко многим с точки зрения практики — это нормально?
Можете оценить надёжность/быстродействие/сопровождаемость такой реализации?
Здравствуйте, Smoke_Jaguar, Вы писали:
S_J>И теперь программист предлагает хранить в таблице "Договор" не один строковый идентификатор работы, а строку с множеством идентификаторов работы разделяемых спец символом "@". Дальше в запросах он это фильтровать собирается.
S_J>Ладно строковые поля в качестве ключа,
Это как раз не страшно
S_J> но такой способ организации отношения один ко многим с точки зрения практики — это нормально?
Нет, это не нормально. Это нарушение первой нормальной формы. Форма это, конечно, не самоцель, но в данном случае лучше ввести третью таблицу "связь".
S_J>Можете оценить надёжность/быстродействие/сопровождаемость такой реализации?
Надёжность — смотря что имеется в виду под надёжностью
Быстродействие — низкое, так как по такой связи индекс не построить, плюс, при каждом соединении таблиц будет лишний парсинг строки
Сопровождаемость — низкая, так как решение нестандартное и кривое, поэтому каждый новый работающий над проектом будет тратить врямя на то, чтобы постебаться над автором такого решения . Ну и, естественно, будет куча проблем, если к этим связям потребуется добавить атрибут. Например, дату добавления работы в договор.
S_J>И теперь программист предлагает хранить в таблице "Договор" не один строковый идентификатор работы, а строку с множеством идентификаторов работы разделяемых спец символом "@". Дальше в запросах он это фильтровать собирается.
убейте программиста, спасите человечество! такие не должны дать потомство.
вы должны разбить таблицу на две договор и работу, где работа через ссылается на договор. только так, т.к. когда его убьет кто-то другой и кто-то новый придет супортить вашу систему может не догадаться об изврате с @, не говоря уже о всяких ормах, отчетных тулах и прочая, которые если понадобятся тоже не оценят столь жесткое извращение.
Здравствуйте, Smoke_Jaguar, Вы писали:
S_J>И теперь программист предлагает хранить в таблице "Договор" не один строковый идентификатор работы, а строку с множеством идентификаторов работы разделяемых спец символом "@". Дальше в запросах он это фильтровать собирается.
Smoke_Jaguar wrote:
> Между двумя таблицами связь один ко многим. Пусть будет "Работа" и > "Договор". Договор содержит идентификатор работы (ключ реализован > строкой символов). > > Естественно, быстро выяснилось, что к одному договору может принадлежать > несколько работ. > > И теперь программист предлагает хранить в таблице "Договор" не один > строковый идентификатор работы, а строку с множеством идентификаторов > работы разделяемых спец символом "@". Дальше в запросах он это > фильтровать собирается.
Это было бы нарушением 1НФ, грубая ошибка проектирования БД.
> Ладно строковые поля в качестве ключа, но такой способ организации
Это как раз не страшно.
> отношения один ко многим с точки зрения практики — это нормально?
См. выше.
А последствия для БД -- вы не сможете НОРМАЛЬНО работать с
этими таблицами (с "Договор") с помощью SQL-запросов.
Аноним 456 wrote:
> убейте программиста, спасите человечество! такие не должны дать потомство.
Не, зачем убивать... Не гуманно это.
Именно -- уволить, и обеспечить отсутствие потомства, т.е. оторвать
причинные места. Ну, и если есть уже дети -- либо проверить их
на "правильность", либо не допускать их работу программистами.
Ну а если серьёзно, это -- элементарная безграмотность в проектировании
БД.
. Ну и, естественно, будет куча проблем, если к этим связям потребуется добавить атрибут. Например, дату добавления работы в договор.
