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

Rules: physical model

Правила: исполнение​

Таблицы​

Хранение данных в базе описано в таблицах.

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

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

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

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

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

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

Сам механизм описан в материализациях.

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

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

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

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

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

Индексы​

Сам механизм описан в индексах.

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

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

  3. Составной индекс следует создавать, когда фильтрация идет сразу по нескольким полям одной таблицы; первыми в нём должны идти поля, ограничиваемые равенством, а за ними — поле, ограничиваемое диапазоном: именно на такой форме btree-скан сужается лучше всего.

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

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

Примеры​

Таблица на каждый набор классов ключей, свойство размещено в неё опцией TABLE, материализован читаемый результат — построчный sum оставлен вычисляемым, потому что правило 3 запрещает хранить промежуточный шаг цепочки. В составном индексе поле, ограниченное равенством, стоит перед полем, ограниченным диапазоном, как требует правило 3 правил индексов.

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

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

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

Правила: модули​

  1. Ассистент ОБЯЗАН разбивать код lsFusion на модули по доменной логике или функциональной области, а не по произвольной технической группировке.

  2. Ассистенту СЛЕДУЕТ предпочитать относительно короткие модули.

    Один широкий модуль НЕ ДОЛЖЕН продолжать расти, когда логика естественно разделяется на более мелкие связные модули.

  3. Ассистент ОБЯЗАН применять низкую связанность и высокую связность: тесно связанные классы, свойства, действия и формы СЛЕДУЕТ держать вместе, а межмодульные зависимости СЛЕДУЕТ держать узкими и явными.

  4. NAMESPACE модуля СЛЕДУЕТ выбирать по общему бизнес-домену, а не по полному имени модуля.

  5. Когда модуль относится к существующему семейству доменов, ассистенту СЛЕДУЕТ переиспользовать пространство имён этого семейства для всех его элементов.

    Новое пространство имён СЛЕДУЕТ создавать только для действительно нового домена, а не для каждого технического подмодуля.

  6. Если имя модуля уже совпадает с предполагаемым пространством имён домена, опускание NAMESPACE допустимо, поскольку lsFusion использует имя модуля по умолчанию.

    Иначе ассистенту СЛЕДУЕТ указывать NAMESPACE явно.

  7. Ассистенту СЛЕДУЕТ использовать REQUIRE, EXTEND, абстрактные свойства / действия и расширения форм для связывания модулей вместо дублирования логики или создания god-модуля.

  8. Прежде чем добавлять код в существующий модуль, ассистент ОБЯЗАН проверить, относится ли логика к домену этого модуля.

    Если нет, ассистенту СЛЕДУЕТ создать или расширить более подходящий модуль.

  9. Вводя новый модуль, ассистент ОБЯЗАН осознанно выбирать зависимости и избегать циклических или ненужных зависимостей.

  10. Чтобы использовать свойство, действие, класс или форму из другого модуля, этот модуль ДОЛЖЕН быть достижим из цепочки REQUIRE текущего модуля — напрямую или транзитивно через другие подключённые модули.

    Если модуль-владелец не входит в транзитивное замыкание REQUIRE, платформа выдаёт ошибку «Property not found» (или аналогичную «not found») при запуске.

    Ассистент ОБЯЗАН добавить модуль-владелец (или любой модуль, уже подключающий его) в список REQUIRE текущего модуля до использования его элементов.

  11. Сервер поставляется со встроенными системными модулями, чьи имена НЕЛЬЗЯ переиспользовать для модулей приложения — сервер падает при запуске с ошибкой module '<имя>' has already been added. Встроенные имена: System, Utils, UserEvents, Scheduler, Email, Time, Reflection, Security, Service, Icon, Authentication, SystemEvents, Word, WebSocket, Integration, Profiler, SQLUtils, ProcessMonitor, DefaultData, Image, Printer, Numerator, Chat, Eval, I18n, Com, Sound, Backup, OpenCV, Geo, Historizable, Schedule, Document, QZTray, Excel, Hierarchy, RabbitMQ, MasterData, Messenger, Whatsapp, Skype, Telegram, Viber, Slack.

    Для типовых доменных имён из этого списка (MasterData, Document, Schedule, Numerator) ассистенту СЛЕДУЕТ добавлять к имени модуля префикс проекта.

Правила: миграция (migration.script)​

  1. Переименование свойства или действия, либо его перенос в другое пространство имён, меняет каноническое имя элемента. Всякий раз, переименовывая или меняя пространство имён существующего элемента, ассистент ОБЯЗАН отразить это изменение в migration.script в той же правке; иначе платформа считает старое и новое имена несвязанными элементами — старый удаляется, а новый создаётся пустым.

  2. Для первичного (DATA) свойства это незаметно разрушительно, и ассистент ОБЯЗАН проявлять особую осторожность. Переименование / смена пространства имён ДОЛЖНЫ быть записаны как изменение STORED PROPERTY (старое каноническое имя -> новое каноническое имя), что переименовывает соответствующую колонку в базе данных и сохраняет её данные. Простое изменение PROPERTY переносит только настройки политики безопасности и рефлексии, но НЕ сохранённые данные.

  3. Без записи STORED PROPERTY при следующем старте сервера старая колонка переименовывается в _DELETED_ плюс её прежнее имя в базе — а если колонка с таким именем уже есть, просто удаляется, — а для нового имени создаётся новая пустая колонка, так что все существующие значения свойства теряются. Ассистент НЕ ДОЛЖЕН переименовывать или переносить DATA свойство в другое пространство имён без добавления этой записи.

  4. Переименование пользовательского класса или его перенос в другое пространство имён ДОЛЖНЫ быть записаны как изменение CLASS, чтобы сохранить его объекты и их данные. Такое переименование класса может также изменить канонические имена его DATA свойств; они не отслеживаются автоматически и ДОЛЖНЫ быть добавлены как отдельные изменения STORED PROPERTY.