Что так плохо об использовании ВНУТРЕННЕГО ОБЪЕДИНЕНИЯ SQL

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

Простой пример библиотеки:

Many-many отношения обычно определяются в SQL с тремя таблицами: Книга, Категория, BookCategory.

В этой ситуации Категория является таблицей, которая содержит два столбца: идентификатор, CategoryName.

В этой ситуации я получил вопросы о таблице Category, это потребность? Это может использоваться в качестве справочной таблицы, и в BookCategory таблица хранит CategoryName вместо CategoryID, чтобы мешать иметь, чтобы сделать дополнительное ВНУТРЕННЕЕ ОБЪЕДИНЕНИЕ. (Для этого вопроса мы собираемся проигнорировать изменение, удаление любого CategoryNames),

Вопрос, что так плохо о внутренних объединениях? В каком точка делает их отрицательный момент (общие руководящие принципы как # транзакций, # записей, # участвует в операторе, и т.д.)?

7
задан John Saunders 16 March 2010 в 00:43
поделиться

5 ответов

Ваш пример является хорошим контрпримером. Как вы переименуете категории, если они распределены по разным строкам таблицы BookCategory? Ваш UPDATE для переименования затронет все строки одной категории.

При использовании отдельной таблицы вам нужно обновить только одну строку. Дублирующей информации нет.

5
ответ дан 7 December 2019 в 05:21
поделиться

Меня больше беспокоят ВНЕШНИЕ присоединения и возможность получить информацию, которой не было предназначены.

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

Выполнение INNER-соединения не так уж плохо, это то, для чего созданы базы данных. Единственный раз, когда это плохо, - это когда вы делаете это для таблицы или столбца, которые неадекватно проиндексированы.

3
ответ дан 7 December 2019 в 05:21
поделиться

Когда вы отображаете свою доменную модель на реляционную модель, вы должны разделить информацию на множество отношений, чтобы получить нормализованную модель - без этого не обойтись. А затем вы должны использовать соединения, чтобы снова объединить отношения и получить свою информацию. Единственное, что здесь плохо, - это то, что соединения относительно дороги.

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

Единственная причина не нормализовывать реляционную модель (которую я могу придумать на данный момент) - это то, что производительность чтения чрезвычайно - и я имею в виду чрезвычайно - критична.

Кстати, почему вы (они) упоминаете только внутренние соединения? Чем левые, правые и полные внешние соединения существенно отличаются от внутренних?

0
ответ дан 7 December 2019 в 05:21
поделиться

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

Конкретно о том, что INNER JOINs неэффективны или плохи... JOINы - это центр реляционных БД, и они существуют уже несколько десятилетий. Это неправильно только тогда, когда вы используете его неправильно, потому что очевидно, что кто-то делает это правильно, поскольку он еще не вымер. Лично я полагаю, что все, кто делает подобные заявления, либо не знают SQL, либо знают достаточно, чтобы попасть в беду. В следующий раз, когда это всплывет, научите их использовать кэш запросов.

(Не говоря об обновлении/удалении, но вы не сказали о вставках!: повышение удобства обслуживания за счет избежания людей и их опечаток может легко стоить по крайней мере 10-кратного увеличения времени, которое займет соединение)

.
0
ответ дан 7 December 2019 в 05:21
поделиться

Я не уверен, что во внутреннем объединении как таковом есть что-то плохое, это как если бы каждый IF, который вы добавляете в свой код, влиял на производительность (или я должен сказать, каждая строка...), но все же, вам нужно минимальное количество этих строк, чтобы ваша система работала (да-да, я знаю о машинах Тьюринга). Так что если у вас есть что-то ненужное, это будет воспринято с неодобрением.

0
ответ дан 7 December 2019 в 05:21
поделиться
Другие вопросы по тегам:

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