Что быстрее: много строк или много столбцов? - PullRequest
2 голосов
/ 29 июля 2009

В MySQL, как правило, быстрее / эффективнее / масштабируемо возвращать 100 строк с 3 столбцами или 1 строку с 100 столбцами?

Другими словами, при хранении множества пар ключ => значение, относящихся к записи, лучше хранить каждую пару ключ => значение в отдельной строке с ключом record_id или иметь одну строку на record_id с колонкой для каждого ключа?

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

Редактировать: чтобы уточнить, под «регулярной основе» я подразумеваю добавление или удаление ключа один раз в месяц или около того.

Ответы [ 5 ]

10 голосов
/ 29 июля 2009

Никогда не следует добавлять или удалять столбцы на регулярной основе.

2 голосов
/ 29 июля 2009

http://en.wikipedia.org/wiki/Entity-Attribute-Value_model

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

1 голос
/ 29 июля 2009

Если вы храните пары ключ / значение, у вас должна быть таблица с двумя столбцами, один для ключа (сделайте это PK для таблицы) и один для значения (вероятно, этот индекс вообще не нужен) , Помните: «Ключ, весь ключ и ничего, кроме ключа».

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

1 голос
/ 29 июля 2009

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

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

0 голосов
/ 29 июля 2009

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

Второе: разделите ваши наиболее часто используемые данные и поместите их в свою собственную таблицу, а остальные - в другую. Кстати, 100 столбцов - это много, поэтому я рекомендую разбить ваши данные на более мелкие части, которые будут более управляемыми.

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

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