Вопрос столбцов столбцов - дубликаты имен с идентификаторами или нет?

Question

Я не слишком хорошо знаком с запросами, но вот вопрос: Моей «соседство» таблица имеет столбцы:

n_id, name, country_id, continent_id, city_id. 

Где n_id = PK и COUNTRY_ID, continent_id, CITY_ID является ФКСОМ в свои собственные таблицы.

Образец данных:

34, Brooke, 23, 3, 1456 

Этот вывод хорошо для отношений данных, но не для вывода пользователя. На стороне пользователя, когда они видят Brooke на веб-сайте, это должно быть; Brooke, Нью-Йорк - США. (Итак, по существу: Брук, 1456-23).

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

n_id, name, country_id, country_name, continent_id, city_id, city_name 

Какова разница в производительности с обоими способами? Или преимущества или недостатки?

** Сайт является социальной сетью, если это помогает.

Answer 1

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

Что касается производительности, данные, поступающие из одной таблицы, естественно быстрее, чем из двух таблиц.

Answer 2

Как правило, лучше нормализовать данные, а затем де-нормализовать, чтобы решить определенную проблему с производительностью. У вас проблемы с производительностью? Можете ли вы установить параметр ID-only и проверить его?

Ваш первый дизайн таблицы имеет все нормальные преимущества нормализации данных (Google Insertion, Deletion and Update Anomaly). Если у вас есть имя (а также идентификатор или без идентификатора в таблице соседства, у вас должен быть процесс, который гарантирует, что он всегда один и тот же (например, выбранный из предварительно заполненного выпадающего списка без ключа и т. Д.) И способ обновления это если имя изменение и т.д.

Если у вас есть проблемы реальной производительности это может стоить дополнительных effoprt. Otherwaise остаются с нормированным раствором.

Answer 3

не повторяйте данные в транзакционной базе данных.

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

С другой стороны, хранилища данных часто копируют данные для оптимизации отчетности по неизменной исторической информации.

Answer 4

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

Я бы держать 2 вещи в виду:

1. Как правило, никогда не оптимизировать что-то, пока не продемонстрировали необходимость optimze его (правило Abrash в # 1)
2. Если вы обнаружили, что ваш присоединяется нужно быть быстрее, первая оптимизация - это настроить ваши индексы. Это позволит вам быстро присоединяться, не теряя при этом эффекта нормализованного дизайна.

Answer 5

Основным недостатком предлагаемого денормализованного дизайна является то, что правильные ограничения ссылочной целостности и действия по обновлению становятся чрезмерно сложными. Если данные, связанные с City_ID 1456, изменяются, вам необходимо не только изменить одну строку в таблице City, но также вы должны изменить сохраненное значение в каждой из строк NBighbourhood, которая перекрестно ссылается на таблицу City (содержит City_ID = 1456) , Эти «аномалии обновления» являются основной причиной дисциплины нормализации.

Производительность сложно измерить; это будет зависеть от СУБД и размера таблиц, но вполне возможно, что объединение небольших таблиц будет быстрее, чем сканирование всей большой таблицы (где «большая таблица» - это предлагаемая вами пересмотренная таблица соседства, раздутая всеми дополнительные данные, которые вы хотите добавить). Если вы, например, не указали столбцы City_ID и City_Name в таблице «Соседства» (таким образом, используя больше места в индексах, чем в нормализованном дизайне), ваши сканирование для всех людей в одном городе может занять больше времени (поскольку весь таблица соседства должна читаться последовательно), чем индексированный поиск в таблице City, чтобы найти City_ID, а затем индексный указатель точно для правильного City_ID в таблице Соседства.

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

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