Увеличение или уменьшение производительности при использовании таблицы связей, даже когда существует только отношение один ко многим

Question

Я собираюсь создать веб-приложение на PHP и уже решил использовать Codeigniter + DataMapper (издание OverZealous) .

Я обнаружил, что DataMapper (издание OverZealous) требует использования дополнительной таблицы ассоциаций, даже если на самом деле существует только отношение один-ко-многим.

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

[countries] country_id(pk), country_name
[players] player_id(pk), player_name, country_id(fk)

Однако в DataMapper требуется, чтобы дизайн был таким:

[countries] country_id(pk), country_name
[players] player_id(pk), player_name 
[asso_countries_players] countries_players_id(pk), country_id(fk), player_id(fk)

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

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

Answer 1

«Самый быстрый способ сделать что-либо - это вообще не делать».- Кэри Миллсап, Оптимизация производительности Oracle .

«Дизайнер знает, что он достиг истинной элегантности не тогда, когда нечего добавить, а когда нечего убрать».- Антуан де Сент-Экзюпери

Более простая реализация имеет две таблицы и три индекса, два уникальных.Более сложная реализация имеет три таблицы и пять индексов, четыре уникальных.Индекс на asso_countries_players.player_name (, который должен быть суррогатным идентификатором - что произойдет, если имя игрока изменится, например, если он выйдет замуж или изменит его по закону, как Чад Очоцинко (урожденный Джонсон) ?) Должентакже быть уникальным, чтобы обеспечить 0..1 характер отношений между игроками и странами.

Если ассоциативная сущность не требуется моделью данных, устраните ее.Обычно довольно просто преобразовать отношение 0..1 или 1..n в отношение n..n:

1. Добавить ассоциативную сущность (и я бы поставил под сомнение необходимость использования суррогатного ключаесли только у самой связи не было атрибутов, таких как дата начала или окончания)
2. Заполнить ассоциативную сущность существующими данными
3. Переопределить ограничения внешнего ключа
4. Удалить замененный столбец внешнего ключа вдетский стол.

Answer 2

Выбор данных и поиск будут означать больше объединений: вам придется работать с 3 таблицами вместо 2.

Вставка данных будет означать больше запросов на вставку: вам придется вставить в 3 таблицы вместо 2.

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

Answer 3

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

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