Действительно ли нужны таблицы отношений?

Таблицы взаимосвязи в основном содержат две колонки: IDTABLE1 и IDTABLE2.Действительно ли нужны таблицы отношений?

Единственное, что, по-видимому, меняется между таблицами отношений, это имена этих двух столбцов и имя таблицы.

Было бы лучше, если мы создадим одну таблицу Relationships и в этой таблице мы помещаем 3 колонки:
TABLE_NAME, IDTABLE1, IDTABLE2, а затем использовать эту таблицу для всех отношений?

Является ли это хорошим/приемлемым решением в разработке приложений для веб-приложений? Что было бы недостатком этого?

Примечание:
Благодарим вас за отзыв. Я ценю это.
Но, я думаю, вы слишком далеко от него ... Каждое решение работает до одной точки.
Как для хранения данных простой текстовый файл хорош до определенной точки, чем лучше, чем MS Access, чем SQL Server, чем ...
Если честно, я не видел никаких аргументов, в которых говорится, почему это решение плохо для небольших проектов (с размером БД в несколько ГБ).

источник

2011-02-08 This is it

Почему бы не сделать этот шаг дальше и просто сделать одну огромную таблицу с 4 столбцами: TABLE_NAME, ID, COLUMN_NAME, VALUE? –

@Martinho Fernandes - Конечно, вам нужны только три столбца, идентификатор и имя_столбца могут быть объединены вместе с помощью подчеркивания. – Paddy

@ Падди: Нет, это будет микро-оптимизация. И это помешает вам использовать символы подчеркивания в ваших идентификаторах. –

Плохая идея.

Как бы вы применяли внешние ключи, если IDTABLE1 могли содержать id s из любого стола?

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

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

источник

2011-02-08 11:49:25

И не было бы никаких реальных преимуществ для такого громоздкого подхода. +1 – alex

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

источник

2011-02-08 11:49:31 alex

Хороший ответ, плюс с таким дизайном таблицы отношений, было бы очень трудно предотвратить дублирование или сиротские записи. – futile

Еще один плюс: если вы в конечном итоге нуждаетесь в некоторых дополнительных данных о взаимоотношениях, вы ввернуты. –

Кроме того, обновление такой таблицы было бы кошмаром, особенно с сотнями тысяч записей. – alex

Разве это не большой вопрос, что вы собираетесь хранить только 2 поля? Если у меня есть таблица StudentCourse (или еще лучшая регистрация), которая имеет StudentID & CourseID, но не будет EnrollmentDate идти в этой таблице, так как не все учащиеся зачисляются в первый день занятий. Кажется, что плохая идея добавить этот столбец в уже раздутую таблицу, где большинство записей будет нулевым.

Преимущество одной таблицы может быть требованием того, чтобы приложение позволяло пользователю/администратору создавать эти отношения с данными (аналогично одной таблице поиска или таблицы списков ссылок) и избегать создания нового таблицу для обращения к этим пользовательским ссылкам. Необходимость динамического запроса также может пригодиться. Приложение, требующее таких требований к динамической структуре данных, может быть лучше подходит для базы данных schemaless или nosql.

источник

2014-05-06 22:21:53 JeffO

Действительно ли нужны таблицы отношений?

ответ

Смежные вопросы