Оптимальная структура базы данных - "более широкая" таблица с пустыми полями или большим количеством таблиц?

Мне нужно вставить дополнительные данные в базу данных, и у меня есть выбор между изменением существующей таблицы (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 поля.

Если бы мне нужно было с Option (A), у меня было бы много значений empty/NULL в таблице "более широкий".

Если я иду с Option (B), я в основном создаю больше таблиц... один для "каждой" комбинации SP, SV - всего будет 4-5. Но каждый из них будет полностью заполнен правильным количеством полей. table_existing также будет изменен.

Какая более оптимальная структура базы данных с точки зрения скорости? Я думаю, что с точки зрения удобства обслуживания вариант (B) может быть лучше.

Edit1

Ни один из двух параметров не будет наиболее критичным/часто используемым таблицей в моем приложении.

В Варианте (B) после того, как данные были разделены, не было бы необходимости ПРИСОЕДИНИТЬСЯ к ним вообще. Если я знаю, что мне нужны поля для XX_1, я пойду к этому столу.

Я пытаюсь понять, есть ли плюсы и минусы для наличия ОДНОЙ большой таблицы со многими неиспользованными значениями, а также с тем же разделением данных на большее количество таблиц. Увеличивает ли большее количество таблиц производительность в базе данных (у нас уже есть 80 таблиц)?

Ответ 1

Какова более оптимальная структура базы данных с точки зрения скорости?

Хорошо, что правильно, передовая практика и т.д. называется нормализацией. Если вы сделаете это правильно, не будет никаких дополнительных столбцов (а не полей), без Nulls. Дополнительные столбцы будут в отдельной таблице с меньшим количеством строк. Конечно, вы можете расположить таблицы так, чтобы они были наборами необязательных столбцов, а не (один PK плюс) по одному столбцу.

Объединять строки из подкатегорий в одну строку 5NF легко, сделать это ia view (но не обновлять через представление, делать это непосредственно для каждой подкатегории через транзакционную сохраненную процедуру).

Больше, меньшие таблицы - это характер нормализованной реляционной базы данных. Привыкай к этому. Меньше, большие таблицы медленнее, из-за отсутствия нормализации, дубликатов и Nulls. Объединение является громоздким в SQL < но это все, что у нас есть. В самих объединениях нет затрат, только соединяются таблицы (строки, ширина строки, столбцы объединения, типы данных, несоответствия, индексы [или нет]). Базы данных оптимизированы для нормализованных таблиц, а не для кучи данных. И большое количество таблиц.

Это, пожалуй, оптимальная производительность, не удивительно. По двум причинам:

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

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

Ответ не изменяется независимо от того, рассматриваете ли вы 4 или 400 новых таблиц.

Одна рекомендация, если вы серьезно относитесь к тому, что многие таблицы: вы направляетесь в направлении Шестой нормальной формы, не осознавая этого. Так что осознайте это и сделайте это формально. 400 таблиц будут намного лучше контролироваться. Если у вас есть профессионал, чтобы сделать это, они нормализуют это, а в итоге получат меньше 100.

Ответ 2

Я являюсь администратором SQL-сервера SQL, поэтому я буду предлагать, что я буду делать в SQL Server 2008.

Добавьте столбцы в существующую таблицу как NULL, обозначив столбцы как SPARSE. Использование разреженного тега не будет увеличивать объем хранилища для дополнительных столбцов на существующих страницах таблицы и по-прежнему позволяет запрашивать разреженные столбцы в виде столбцов. SQL Server хранит разреженные столбцы внутри XML-формата, которые также могут быть запрошены или отображены.

Если есть устаревшие приложения, которые не могут обрабатывать новую структуру таблицы

переименовать таблицу
Создайте представление с исходной структурой таблицы и назовите его имя исходной таблицы

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

Ответ 3

У ваших запросов больше шансов объединить строки с (XX, 1), установленные с (YY, 2) и т.д....?

Если нет, то разделение на отдельные таблицы выполняется быстрее, так как отдельные таблицы, используемые для всех запросов, уже.

Если вы их объедините, они могут быть немного медленнее, так как вам понадобятся UNION, для которых потребуется дублировать запросы к основной таблице.

Ответ 4

Я согласен с DVK, что если вы выберете (B), вам придется запросить несколько таблиц, чтобы получить все исходные значения Field1, не говоря уже о сложности JOIN и т.д. Это не имело бы смысла, если бы не разделить на отдельные таблицы также соответствовали разделению на разные объекты.

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

Ответ 5

Я помню эти сомнения раньше.

С точки зрения проверки данных опция (B) оказывается более благоприятной. Вы можете помещать ограничения на поля лучше. Именно поэтому вы хотели бы разбить, скажем, таблицу users на students, teachers и т.д., Чтобы обеспечить ограничение NOT NULL в зависимости от роли пользователя.

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

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

Изменить: Если вас беспокоит количество таблиц в вашей базе данных, я предлагаю вам посмотреть здесь.