Что быстрее: много строк или много столбцов?

Question

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

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

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

Изменить. чтобы уточнить на "регулярной основе" " Я имею в виду добавление или удаление ключа один раз в месяц или около того.

Answer 1

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

Answer 2

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

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

Answer 3

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

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

Answer 4

Если вы храните пары ключ / значение, у вас должна быть таблица с двумя столбцами, один для ключа (сделайте это PK для таблицы) и один для значения (вероятно, этот индекс вообще не нужен) , Запомните " ключ, весь ключ и ничего кроме ключа. & Quot;

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

Answer 5

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

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

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