# Сущность
Как известно все данные лежат в базе, в таблицах. Мы привыкли что для использования этих данных в клиентском приложении необходимо создать сущность под каждый набор данных, под каждую таблицу. Тоже самое и в нашем конфигураторе. Если мы хотим использовать данные какой-либо таблицы, мы должны сначала зарегистрировать сущность этой таблицы (подробнее, с практической точки зрения, см. пошаговое описание в Пример конфигурирования простого справочника).
Как и в обычной сущности в традиционном программировании, если какие-либо столбцы не понадобятся на клиентской стороне (на них не нужно будет делать маппинг и т.п.), то эти столбцы можно не перечислять в метаданных Сущности. Можно даже при автоматическом втягивании, намеренно удалить эти столбцы (только не удаляйте первичный ключ). Также столбцы можно удалить, если они уже перечислены в базовой сущности, в том числе и первичный ключ (главное чтобы он был где-нибудь, в базовой или в самой сущности).
Вся структура, таблицы, связи, индексы, ограничения, вьюхи - редактируются в MSSMS. Конфигуратор лишь импортирует эту структуру и использует в своей логике.
Сущность это очень простой объект. Его метаданные это имя таблицы, имя сущности, комментарий и набор столбцов.
При корректном заполнении комментариев и описания столбцов удобно пользоваться SSMS - будет всплывать подсказка с описаниями объектов.
С **именем таблицы** все понятно. Это как называется таблица в MSSQL.
**Имя сущности** - это имя таблицы в единственном числе, без префиксов подсистем. Это имя требуется для полей справочников. Обратите внимание, что при соблюдении соглашения по наименованию таблиц/столбцов, которое мы предлагаем, имя сущности, да и вообще, много всего будет заполняться автоматически.
### Виртуальные столбцы
Сущность может содержать столбцы которых нет в реальной таблице. Например для хранения промежуточных значений при расчетах или для вычисляемых значений в отборах. В примере ниже есть несколько виртуальных столбцов. Все эти значения вычисляются динамически в скрипте загрузки. Тут мы сняли отметки "Использовать в скриптах сохранения" и "Использовать в скриптах загрузки", чтобы данные столбцы не принимали участие в генерируемых скриптах insert и update.
Кстати, используя галку "Использовать в скриптах сохранения" можно исключить существующий (не виртуальный) столбец из скриптов сохранения. Например, можно снять эту галку, если у нас есть столбец, который обновляется каким-либо системным процессом (не пользователем) и если мы хотим гарантировать чтобы пользователь не затер значение этого столбца при очередном редактировании.
Сущность может быть целиком виртуальной, если в ней все поля виртуальные. Такая сущность вообще не будет грузиться или обновляться. Это можно использовать, например если вам требуется загрузить полностью динамические вычисляемые значения. В этом случае переопределяется скрипт загрузки и с помощью своего кастомного sql выражения загружается все что нужно. Об этом читайте в описании [Контекста](/azimut/dokumentaciya/osnovnye-obekty/kontekst.md).
### Кеширование наименований сущности
В процессе работы, система может обращаться к базе для определения наименования сущности по ID. Например, если поле типа Справочник было инициализировано идентификатором, то при отображении этого поля в UI, система будет автоматически определять наименование. Все это создает лишние обращения к базе.
В метаданных сущности добавлено свойство "Кешировать наименования". Если его включить, то после первого определения наименования, система его закеширует.
Данный параметр не следует использовать в таблицах, которые часто редактируются.
Идеальные претенденты на включение кеширования наименований: таблица Status, таблица типов заказов OrderTypes, таблицы адресного классификатора Fias и т.д.
Также можно целиком кешировать всю выборку. Об этом читайте в описании [Контекста](/azimut/dokumentaciya/osnovnye-obekty/kontekst.md).
### Замечание
1. Очень желательно в таблицах в качестве первичных и внешних ключей использовать только тип uniqueidentifier. Для всяких int-ов и varchar-ов не предусмотрен некоторый функционал, там просто поддерживается только uniqueidentifier. И если использовать не uniqueidentifier, а например int, то рано или поздно можно нарваться на ограничение функционала. Например такой прикладной функционал как "История редактирования", "Подписка на редактирование" поддерживают только uniqueidentifier.
2. Если в таблице нужно пользовательское поле Номер, то отдельно от первичного ключа добавляется поле Number с типом int. В метаданных сущности тип - Последовательность. Такое поле будет автоматически нумероваться при сохранении, а также у него будет автоматически создан индекс. Соответственно выборку желательно сортировать именно по этому полю, а не по дате создания.
3. Необходимо первичный ключ всегда назвать "uid".
4. Очень желательно чтобы название внешнего ключа оканчивалось на "ID". Тогда некоторые свойства в метаданных будут заполняться автоматом. Например OrderID.
5. Наименования таблиц начинайте с двух символов обозначающих подсистему и далее символа "подчеркивание". Это также позволит конфигуратору автоматом распознавать и автоматически заполнять некоторые свойства, экономя вам время. Например DP\_Orders.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://projects.itproduct.ru/azimut/dokumentaciya/osnovnye-obekty/sushnost.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.