В любой базе данных обычно есть 2 типа таблиц — измерения и факты:

1. Размеры - это таблицы конфигурации. Эти таблицы не изменяются часто и обычно представляют собой одно текущее значение моментального снимка (возможно, с некоторыми изменениями в истории, подробно описанными ниже). Наиболее распространенными операциями являются правки таблицы. Их также можно рассматривать как Config или Masters.
2. Факты — это таблицы, которые увеличиваются почти линейно со временем. Обычно эти объекты регулярно генерируются со временем, обновления генерируемых фактов не являются обычным явлением и обычно относятся к Измерениям для получения дополнительной информации.

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

Сначала нормальный

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

Отражайте объекты реального мира

Даже если варианты использования/отчеты неясны, объекты схемы должны отражать реальный вариант использования. Такая схема обычно надежна.

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

1. Логически отдельные объекты, которые могут существовать независимо и потенциально без какой-либо связи друг с другом — например, набор данных и станция.
2. Иметь отношения «многие ко многим» или отношения «один ко многим» друг с другом — например, для компании электронной коммерции, заказов и клиентов.

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

Используйте правильные типы полей

1. Перечисление и строковые типы для полей с фиксированным набором значений параметров: перечисления реализованы в виде байтов, поэтому занимают меньше места (например, 1–4 байта длиной byte/long/int против 128-байтовой строки), быстрее/быстрее для индексов и поиски. Для больших таблиц требования к пространству и производительности складываются. Использовать перечисления по умолчанию.
2. Тип первичного ключа (ID): Производительность и хранение — всегда рекомендуется использовать ключ фиксированного размера, т. е. целые числа или UUID.
3. Общие поля таблицы: некоторые поля предлагаются во всех объектах ORM, которые могут изменяться, например, created_at, updated_at, created_by, updated_by. Кроме того, для сущностей, которые часто могут иметь связи с внешним ключом и редко удаляются, предлагается использовать обратимое удаление.

Запрос Дришти может быть сложным и включать несколько объединений. Базы данных оптимизированы для соединений и вычислений в памяти. Везде, где это возможно, выполняйте эти соединения или вычисления в базе данных — либо посредством дополнений к слою ORM, надлежащего запроса или перепроектирования схемы. Эмпирическое правило заключается в том, что объединение больших результатов в коде приложения следует рассматривать только там, где база данных не может сделать это в памяти — например, для соединений между базами данных.

Когда добавлять таблицы истории?

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

Есть 2 способа их сохранения:

1. Поддерживайте общую абстракцию для изменения атрибута, в которой каждая строка в этой истории изменений указывает на тип объекта, атрибут, идентификатор объекта, старое значение и новое значение. Преимущество: не требуется новая таблица для каждого объекта.
2. Ведите таблицу истории сущностей для каждого изменения значения. Преимущество: фиксируйте изменения нескольких полей в виде атомарных транзакций, показывая их клиенту как таковые. Таким образом, концепция транзакции, выполненной пользователем во внешнем интерфейсе или иным образом, сохраняется.