Перейти к основному содержимому
Версия: 7.0

Rules: физическая модель

Область действия​

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

Таблицы​

  1. Таблицы следует объявлять явно для каждого используемого набора классов ключей, а свойства с этим набором параметров — размещать в них опцией TABLE. Автоматически созданной таблицы _auto_... в логике быть не должно: ее имя определяется классами параметров, поэтому изменение сигнатуры свойства приводит к переносу данных в другую таблицу.

  2. Свойства с одинаковым набором параметров, которые обычно читаются вместе, следует хранить в одной таблице: тогда их чтение не требует соединения таблиц.

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

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

  5. Политику именования следует выбирать на старте проекта. Короткая политика делает имена в базе читаемыми, но при большом количестве материализованных свойств требует явных имен полей, чтобы имена оставались уникальными.

Материализации​

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

  2. Материализовать не следует свойства, у которых значение не NULL для бесконечного числа наборов объектов, — такое свойство материализовать нельзя. Типичный случай — свойство с параметром встроенного класса, например датой, не ограниченным условием.

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

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

  5. После изменения определения материализованного свойства или прямого исправления данных в базе хранимые значения следует пересчитать оператором RECALCULATE.

Индексы​

  1. Индексы следует создавать для свойств, по которым выполняется фильтрация или поиск в формах и запросах, и не следует создавать «на всякий случай»: каждый индекс обновляется при каждом изменении значений его полей.

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

  3. Составной индекс следует создавать, когда фильтрация идет сразу по нескольким полям одной таблицы; порядок полей в нем должен соответствовать порядку, в котором эти поля ограничиваются.

  4. Индекс, дублирующий автоматически создаваемые, создавать не следует: уникальный индекс по всем ключам таблицы и индексы по суффиксам ключей уже существуют.

  5. Для полей, по которым выполняется поиск операторами LIKE и MATCH, следует использовать одноименные типы индексов, а не обычный индекс.

Примеры​

TABLE order (Order);
TABLE orderDetail (OrderDetail);
TABLE skuStock (Sku, Stock);

date = DATA DATE (Order) INDEXED;
sum (OrderDetail d) = quantity(d) * price(d) MATERIALIZED;
sum (Order o) = GROUP SUM sum(OrderDetail d) BY order(d) MATERIALIZED;

INDEX customer(Order o), date(o);