Лучше разбить таблицу и создать новую таблицу, которая будет иметь 3 столбца + внешний идентификатор, или просто сделать это n + 3 столбца и не использовать объединения? - PullRequest
2 голосов
/ 07 апреля 2010

Я проектирую базу данных для проекта. У меня есть таблица с 10 столбцами, большинство из которых используются при каждом обращении к таблице, и мне нужно добавить еще 3 столбца;

View Count
Thumbs Up (count)
Thumbs Down (Count)

, который будет использоваться в% 90 запросов при обращении к таблице. Итак, мой вопрос заключается в том, что лучше разбить таблицу и создать новую таблицу, которая будет иметь эти 3 столбца + внешний идентификатор, или просто сделать из нее 13 столбцов и не использовать объединений?

Поскольку эти столбцы будут использоваться часто, я думаю, что лучше добавить еще 3 столбца, но если мне нужно создать еще 10 столбцов, которые будут использоваться в 90% случаев, я должен добавить их также или создать новый таблица и использовать объединения?

Я не уверен, когда разбивать таблицу, если столбцы используются очень часто. У вас есть предложения?

Ответы [ 6 ]

5 голосов
/ 07 апреля 2010

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

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

2 голосов
/ 07 апреля 2010

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

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

1 голос
/ 07 апреля 2010

То же самое и раньше. В 95% случаев вы должны создавать свои таблицы на основе логических объектов. Если у вас есть 13 элементов данных, которые описывают одну и ту же «вещь», то все они принадлежат одной таблице. Не разбивайте их на несколько таблиц, основываясь на том, как часто вы ожидаете, что они будут использоваться или использоваться вместе. Это обычно создает больше проблем, чем решает.

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

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

1 голос
/ 07 апреля 2010

Частота использования не должна иметь значения для макета вашей таблицы, по крайней мере, до тех пор, пока вы не начнете с огромных таблиц (в количестве строк или столбцов)

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

0 голосов
/ 07 апреля 2010

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

0 голосов
/ 07 апреля 2010

Мой совет такой же, как у cedo: идите с 13 столбцами.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...