отношения many-many в проектировании баз данных

Если у Вас есть 64-разрядная ОС вместо i686, Вы имеете x86_64 или ia64 в выводе uname -a. В этом у Вас нет ни одной из этих двух строк; у Вас есть 32-разрядная ОС (обратите внимание, что это не означает, что Ваш ЦП не является 64-разрядным).

7
задан ak3nat0n 13 August 2009 в 18:21
поделиться

5 ответов

Нет ничего плохого в том, чтобы иметь отношение «многие ко многим», вам просто нужно создать Junction Table (это звучит так, будто вы ссылаясь на articleTags ), чтобы облегчить эти отношения.

17
ответ дан 6 December 2019 в 06:03
поделиться

Вы видите разницу между концептуальным дизайном базы данных (отношение N: N) и его физической реализацией. Независимо от того, как вы моделируете отношения N: N, вам понадобится вышеупомянутая таблица соединений, чтобы заставить их работать.

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

Когда дело доходит до любого вопроса о производительности в любой системе, ответ обычно сводится к «зависит от обстоятельств».

Если ваша проблема с производительностью связана с WRITES, тогда лучше всего будет сильно НОРМАЛИЗОВАННАЯ структура, и вам понадобится эта Junction table. В конечном итоге вы напишете намного меньше данных, что может существенно ускорить процесс (хотя вы можете сжечь это преимущество, выполняя поиск перед созданием вставок). Чтение из отдельных нормализованных таблиц также может быть очень быстрым.

Если ваша проблема связана с аналитическими СЧИТЫВАНИЯМИ, то лучше всего использовать ДЕНОРМАЛИЗОВАННУЮ структуру. Соединения могут быть очень затратными по производительности, если таблицы большие, а индексы разнесены. Вы пожертвуете много места, чтобы выиграть много времени.

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

Вы пожертвуете большим количеством места, чтобы выиграть много времени.

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

Вы пожертвуете большим количеством места, чтобы выиграть много времени.

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

6
ответ дан 6 December 2019 в 06:03
поделиться

Отношения «многие ко многим» существуют в реляционной модели, это просто абстракция разума. Когда вы его реализуете, появится таблица article_to_tags, в которой у вас будет:

fk_article (INTEGER) fk_tag (INTEGER)

ср http://en.wikipedia.org/wiki/Many-to-many_ (data_model)

4
ответ дан 6 December 2019 в 06:03
поделиться

Нет проблем с использованием отношений "многие ко многим". Это часто требуется.

И да, невозможно создать отношение «многие ко многим» без использования третьей таблицы.

2
ответ дан 6 December 2019 в 06:03
поделиться

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

1
ответ дан 6 December 2019 в 06:03
поделиться
Другие вопросы по тегам:

Похожие вопросы: