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

Question

Таблицы отношений в основном содержат два столбца: IDTABLE1 и IDTABLE2.

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

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

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

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

Answer 1

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

Answer 2

Плохая идея.

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

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

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

Answer 3

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

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