Насколько эффективна таблица данных?

Question

В моей работе у нас есть псевдостандарт создания одной таблицы для хранения «стандартной» информации для сущности и второй таблицы, названной как «TableNameDetails», которая содержит необязательные элементы данных. В среднем для каждой строки в основной таблице будет около 8-10 строк подробностей.

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

Answer 1

8-10 деталей строк или 8-10 деталей столбцов ?

Если его строки, то вы смешиваете яблоки и апельсины, так как отношение один-ко-многим не может быть сведено в столбцы.

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

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

Answer 2

Является ли ваша таблица данных таблицей значений сущностей? В таком случае, да, вы просите о проблемах производительности.

Answer 3

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

Неверное указание чего-либо в качестве детали, которая должна быть стандартной, вероятно, является худшей вещью.Потому что вы не можете требовать, чтобы строка существовала так же просто, как требование наличия столбца (большой сложный триггерный код).Установка по умолчанию для типа строки: lot hardder (большой сложный код ограничения).И индексация тоже не легка (разреженный индекс, может быть?).

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

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

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

Answer 4

То, что вы описываете, является дизайном Entity-Attribute-Value. У них есть свое место в мире, но их следует избегать как чумы, если в этом нет крайней необходимости. Я всегда приводил аналогию в том, что они похожи на наркотики: в небольших количествах и при определенных обстоятельствах они могут быть полезны. Слишком много тебя убьет. Их производительность будет ужасной и не будет масштабироваться, и вы не получите никакой целостности данных для значений, поскольку все они хранятся в виде строк.

Итак, краткий ответ на ваш вопрос: если вам никогда не нужно запрашивать конкретные значения, и вам никогда не нужно составлять столбчатый отчет об атрибутах данного объекта, ни заботиться о целостности данных, ни делать что-либо, кроме как выплевывать всю пачку данные для объекта в виде списка, они в порядке. Однако если вам действительно нужно их использовать, какой бы запрос вы ни написали, он не будет эффективным.

Answer 5

Вы смешиваете две разные модели данных - доменную для «стандартной» и ключ / значение для «расширенной» информации.

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

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