Более эффективно иметь больше столбцов или больше строк?

Question

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

item_id | user_id | title | description | content | category | template | comments | status 
------------------------------------------------------------------------------------------- 
1  | 1  | ABC | DEF   | GHI  | 1  | default | 1  | 1 
2  | 1  | ZYX |    | QWE  | 2  | default | 0  | 1 
3  | 1  | A  |    | RTY  | 2  | default | 0  | 0 
4  | 2  | ABC | DEF   | GHI  | 3  | custom | 1  | 1 
5  | 2  | CBA |    | GHI  | 3  | custom | 1  | 1 

Versus что-то в следующем составе:

item_id | user_id | attribute | value 
--------------------------------------- 
1  | 1  | title  | ABC 
1  | 1  | description | DEF 
1  | 1  | content  | GHI 
...  | ...  | ...   | ... 

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

Итак, мой вопрос: эффективнее ли использовать несколько столбцов или несколько строк - с точки зрения скорости запроса и дискового пространства. Или вы бы вместо этого предложили таблицы отношений, так что есть таблица для блогов, таблица для событий и т. Д. Я просто пытаюсь найти легко расширяемое решение, где я в идеале не хочу создавать таблицу для каждого типа поскольку я думаю о разработчиках, создающих новые виды контента через систему app/API (с жестко контролируемыми атрибутами).

Дополнительный вопрос, если несколько строк

Как я мог, в MySQL, конвертировать несколько строк в удобный формат колонок (я предполагаю, что временные таблицы) - так что я мог бы сделать некоторую фильтрацию по типу контента, в качестве примера ,

Answer 1

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

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

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

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

Answer 2

В принципе, mysql имеет переменную длину строки, если не изменять значение для каждого уровня таблицы. Таким образом, пустые cols не будут использовать какое-либо пространство (ну, почти).

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

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

Answer 3

Этот вопрос очень сложно ответить, поскольку все сводится к тому, что вы ищете и как ваша база данных будет расти по размеру и сложности с течением времени.Я считаю, что лучший способ ответить на эти вопросы - прочитать примеры из других успешных сайтов. Например, Reddit будет примером, где они используют много строк, но очень маленькие таблицы и/или столбцы. Статья here, и вопрос на нем here.

Существует также возможность изучения решения NoSQL, которое может быть более применимым к тому, чего вы пытаетесь достичь.

Примеры из практики, основанные на Google, которые будут иметь сходную структуру по своему усмотрению и посмотреть, как они ее достигли, поскольку они, скорее всего, столкнулись со всеми проблемами, которые вы будете и уже преодолели.