Сущность

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

Как и в обычной сущности в традиционном программировании, если какие-либо столбцы не понадобятся на клиентской стороне (на них не нужно будет делать маппинг и т.п.), то эти столбцы можно не перечислять в метаданных Сущности. Можно даже при автоматическом втягивании, намеренно удалить эти столбцы (только не удаляйте первичный ключ). Также столбцы можно удалить, если они уже перечислены в базовой сущности, в том числе и первичный ключ (главное чтобы он был где-нибудь, в базовой или в самой сущности).

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

Сущность это очень простой объект. Его метаданные это имя таблицы, имя сущности, комментарий и набор столбцов.

При корректном заполнении комментариев и описания столбцов удобно пользоваться SSMS - будет всплывать подсказка с описаниями объектов.

С именем таблицы все понятно. Это как называется таблица в MSSQL.

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

Виртуальные столбцы

Сущность может содержать столбцы которых нет в реальной таблице. Например для хранения промежуточных значений при расчетах или для вычисляемых значений в отборах. В примере ниже есть несколько виртуальных столбцов. Все эти значения вычисляются динамически в скрипте загрузки. Тут мы сняли отметки "Использовать в скриптах сохранения" и "Использовать в скриптах загрузки", чтобы данные столбцы не принимали участие в генерируемых скриптах insert и update.

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

Сущность может быть целиком виртуальной, если в ней все поля виртуальные. Такая сущность вообще не будет грузиться или обновляться. Это можно использовать, например если вам требуется загрузить полностью динамические вычисляемые значения. В этом случае переопределяется скрипт загрузки и с помощью своего кастомного sql выражения загружается все что нужно. Об этом читайте в описании Контекста.

Кеширование наименований сущности

В процессе работы, система может обращаться к базе для определения наименования сущности по ID. Например, если поле типа Справочник было инициализировано идентификатором, то при отображении этого поля в UI, система будет автоматически определять наименование. Все это создает лишние обращения к базе.

В метаданных сущности добавлено свойство "Кешировать наименования". Если его включить, то после первого определения наименования, система его закеширует.

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

Идеальные претенденты на включение кеширования наименований: таблица Status, таблица типов заказов OrderTypes, таблицы адресного классификатора Fias и т.д.

Также можно целиком кешировать всю выборку. Об этом читайте в описании Контекста.

Замечание

1. Очень желательно в таблицах в качестве первичных и внешних ключей использовать только тип uniqueidentifier. Для всяких int-ов и varchar-ов не предусмотрен некоторый функционал, там просто поддерживается только uniqueidentifier. И если использовать не uniqueidentifier, а например int, то рано или поздно можно нарваться на ограничение функционала. Например такой прикладной функционал как "История редактирования", "Подписка на редактирование" поддерживают только uniqueidentifier.

2. Если в таблице нужно пользовательское поле Номер, то отдельно от первичного ключа добавляется поле Number с типом int. В метаданных сущности тип - Последовательность. Такое поле будет автоматически нумероваться при сохранении, а также у него будет автоматически создан индекс. Соответственно выборку желательно сортировать именно по этому полю, а не по дате создания.

3. Необходимо первичный ключ всегда назвать "uid".

4. Очень желательно чтобы название внешнего ключа оканчивалось на "ID". Тогда некоторые свойства в метаданных будут заполняться автоматом. Например OrderID.

5. Наименования таблиц начинайте с двух символов обозначающих подсистему и далее символа "подчеркивание". Это также позволит конфигуратору автоматом распознавать и автоматически заполнять некоторые свойства, экономя вам время. Например DP_Orders.