MySQL InnoDB Дизайн Вопрос

Question

Надеюсь, простой вопрос:

Было бы лучше создать 1) одну таблицу «документ» с десятками тысяч записей или 2) разбить их на несколько таблиц «тип документа»?

Например, 1) таблица «document» со столбцами user_id, document_type и document_name или 2) отдельные таблицы «document_type» со столбцами user_id и document_name.

В любом случае мы имеем дело с десятками тысяч записей.

Мои инстинкты говорят мне, что вариант 1 может привести к значительному снижению производительности по сравнению с вариантом 2.

Спасибо!

Answer 1

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

• Будет сложнее поддерживать код

• Производительность выбора будет страдать

• целостность данных не будет исполнение

Редактировать: улучшено форматирование

Answer 2

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

В вашем случае, предположим, у вас есть 90K записей с 30K каждого из трех типов. Если вы индексируете столбец document_type, запрос, выбирающий один из трех типов, будет почти таким же быстрым, как и выбор таблицы, содержащей 30 тыс. Записей только одного типа.

Кроме того, поскольку идентификатор документа, скорее всего, будет представлять собой числовой индекс с высокой степенью кардинальности, при условии, что вы индексируете столбец - что вам следует сделать, это должен быть первичный ключ - выбор записи определенного индекса будет таким же, как быстро для таблицы с записями 90 КБ трех типов, как для таблицы из 30 КБ одного типа.

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

Answer 3

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

То есть вместо:

document
 - document_id (pk)
 - type
 - name
 - attribute_x
 - attribute_y
 - attribute_z
 - attribute_a
 - attribute_b
 - attribute_c
 - attribute_1
 - attribute_2
 - attribute_3

Вы создаете таблицу для каждого подкласса документа:

document
 - document_id (pk)
 - type
 - name

document_type_1
 - document_id (pk) references document(document_id)
 - attribute_x
 - attribute_y
 - attribute_z

document_type_2
 - document_id (pk) references document(document_id)
 - attribute_a
 - attribute_b
 - attribute_c

document_type_3
 - document_id (pk) references document(document_id)
 - attribute_1
 - attribute_2
 - attribute_3

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

Answer 4

Ваша производительность для первого варианта не должна быть слишком плохой при правильной индексации.Похоже, вы захотите проиндексировать document_name, а затем, возможно, одно из других полей.Отчасти это зависит от того, сколько вы будете вставлять, а также от запросов;если вставки будут редкими, вы можете позволить себе больше индексирования.