Оптимальная структура базы данных - "широкая" таблица с пустыми полями или большим количеством таблиц?
мне нужно вписать дополнительные данные в базу данных, и у меня есть выбор между изменением существующей таблицы (table_existing) или созданием новых таблиц.
вот как table_existing выглядит прямо сейчас:
table_existing
-------------------------
| ID | SP | SV | Field1 |
| .. | WW | 1 | ...... |
| .. | WW | 1 | ...... |
-------------------------
Вариант (A)
table_existing
----------------------------------------------------------------------
| ID | SP | SV | Field1 | Field2 | Field3 | Field4 | Field5 | Field6 |
| .. | XX | 1 | ...... | ...... | ...... | ...... | ...... | ...... |
| .. | YY | 2 | ...... | ...... | ...... | ...... | ...... | ...... |
----------------------------------------------------------------------
Вариант (B)
table_existing would be converted into table_WW_1_data
---------------
| ID | Field1 |
| .. | ...... |
| .. | ...... |
---------------
table_XX_1_data
------------------------
| ID | Field1 | Field2 |
| .. | ...... | ...... |
| .. | ...... | ...... |
------------------------
table_YY_2_data
---------------------------------
| ID | Field1 | Field2 | Field3 |
| .. | ...... | ...... | ...... |
| .. | ...... | ...... | ...... |
---------------------------------
контекст: комбинация SP, SV определяет "количество" полей, которые будут заполнены. Например, (XX, 1) имеет 2 поля. (YY, 2) имеет 3 поля.
Если Я должен был пойти с опцией (A), у меня было бы много пустых/нулевых значений в "более широкой" таблице.
Если я пойду с опцией (B), я в основном создаю больше таблиц... по одному для" каждой " комбинации SP, SV - всего будет, возможно, 4-5. Но каждый из них будет полностью заполнен правильным количеством полей. table_existing также будет изменен.
какова более оптимальная структура базы данных с точки зрения скорости? я думаю, что от точки зрения ремонтопригодности, вариант (B) может быть лучше.
Edit1
ни один из двух вариантов не будет наиболее критичными / часто используемыми таблицами в моем приложении.
В варианте (B) после разделения данных не было бы необходимости присоединяться к ним вообще. Если я знаю, что мне нужны поля для XX_1, я перейду к этой таблице.
Я пытаюсь понять, есть ли плюсы и минусы для того, чтобы иметь один большой стол со многими неиспользуемыми значениями и с одинаковыми данными, разделенными на большее количество таблиц. Приводит ли большее количество таблиц к повышению производительности в базе данных (у нас уже есть ~80 таблиц)?
5 ответов
какова более оптимальная структура базы данных с точки зрения скорости?
Ну, то, что правильно, лучшая практика и т. д., называется нормализацией. Если вы сделаете это правильно, не будет никаких дополнительных столбцов (полей), не обнуляет. Необязательные столбцы будут находиться в отдельной таблице с меньшим количеством строк. Конечно, вы можете расположить таблицы так, чтобы они были наборами необязательных столбцов, а не (один PK plus) по одному столбцу каждый.
объединение строк из вложенные таблицы в одну строку 5NF легко, сделайте это я представление (но не обновляйте через представление, сделайте это непосредственно для каждой вложенной таблицы, через транзакционный сохраненный proc).
больше, меньшие таблицы, являются природой нормализованной реляционной базы данных. Привыкай к этому. Меньше, большие таблицы медленнее, из-за отсутствия нормализации, дубликатов и нулей. Вступление является сложным в SQL
что, оказывается, является оптимальной производительностью re, неудивительно. По двум причинам:--3-->
таблицы уже, поэтому на странице больше строк, вы получаете больше строк на физический ввод-вывод и больше строк в том же пространстве кэша.
поскольку у вас нет нулей, эти столбцы исправлен len, нет распаковки, чтобы извлечь содержимое столбца.
нет плюсов для больших таблиц со многими необязательными (нулевыми) столбцами, только минусы. Никогда про нарушение стандартов.
ответ остается неизменным независимо от того, рассматриваете ли вы 4 или 400 новых таблиц.
- одна рекомендация, если вы серьезно рассматриваете, что многие таблицы: вы направляетесь в направлении шестой нормальной формы, без осознавая это. Так что осознайте это и сделайте это формально. 400 таблиц будут гораздо лучше контролироваться. Если вы заставите профессионала сделать это, они нормализуют это и в конечном итоге вернутся менее чем на 100.
Я SQL server DBA, поэтому я предложу, что я буду делать в SQL Server 2008.
добавьте столбцы в существующую таблицу как nullable, отметив столбцы как разреженные. Использование тега sparse не увеличивает объем хранилища для дополнительных столбцов на существующих страницах таблицы и позволяет запрашивать разреженные столбцы как столбцы. SQL Server хранит разреженные столбцы внутри в формате XML, которые также могут быть запрошены или отображены.
Если есть устаревшие приложения, которые не удается обработать новую структуру таблицы
- переименовать таблицу
- создайте представление со структурой таблицы origional и назовите его именем таблицы origional
Если у вас есть версия, которая не поддерживает разреженные столбцы, создайте одну дочернюю таблицу для существующей таблицы, связывающей ребенка с родителем с идентификатором родительской таблицы. Создайте представление между двумя таблицами для представления данных.
ваши запросы, скорее всего, потребуется объединить строки для (XX,1) set с (YY,2) set и т. д...?
Если нет, то разделение на отдельные таблицы быстрее, так как отдельные таблицы, используемые для всех запросов, уже.
Если вы объедините их, они могут быть немного медленнее, так как вам понадобятся объединения, которые потребуют повторяющихся запросов к главной таблице.
Я бы согласился с DVK, что если вы выберете (B), вам придется запрашивать несколько таблиц, чтобы получить все исходные значения Field1, не говоря уже о сложности соединений и т. д. Это не имело бы смысла, если бы разделение на отдельные таблицы также не соответствовало разделению на разные сущности.
Я согласен с полом в том, что на ваш вопрос нельзя ответить, не зная деталей вовлеченных объектов и видов запросов и обновлений, которые вы будете бегущий.
Я помню, что у меня были эти сомнения раньше.
С точки зрения проверки данных вариант (B) оказывается более благоприятным. Вы можете лучше разместить ограничения на полях. Именно поэтому вы хотели бы разделить, скажем,users в таблице students, teachers и т. д. Для применения ограничений NOT NULL в зависимости от роли пользователя.
как правило, наличие большого количества нулевых значений в таблице плохо сказывается на производительности из-за индексирования проблемы.
как правило, пока количество таблиц, участвующих в ваших соединениях, равно 4 или меньше, вам не нужно беспокоиться о производительности.
Edit: если вы беспокоитесь о количестве таблиц в базе данных, я предлагаю вам посмотреть здесь.