# Database

## 0. Введение

TODO

## 1. Файлы с исходным кодом

TODO

## 2. Форматирование

### 2.1. Регистр ключевых слов

Ключевые слова записываются в нижнем регистре.

```sql
    -- Плохо
    SELECT * FROM <table>;

    -- Хорошо
    select * from <table>;
```

## 3. Использование возможностей языка

TODO

## 4. Правила именования

### 4.1. Общие правила для всех идентификаторов

a. Используются общие правила именования всех идентификаторов из общих стандартов разработки, [п. 5.1](https://eigenspace.gitbook.io/dev-standards/common#51-------).

b. Для исключения проблем с использованием разного регистра и специальных символов в качестве разделителей заключать идентификатор в двойные кавычки. Они являются техническим средством позволяющим задать требуемое имя и не влияют на отображение имён при просмотре базы данных.

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

### 4.2. Правила для идентификаторов каждого типа

#### 4.2.1. Имена сущностей (таблиц)

Правила именования сущностей соответствуют [правилам именования классов](https://eigenspace.gitbook.io/dev-standards/ru/scripts#421----). Например, `"FinancialInfo"`, `"Company"`.

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

#### 4.2.2. Имена полей сущности (таблицы)

a. Правила именования полей соответсвуют [правилам именования полей классов](https://eigenspace.gitbook.io/dev-standards/ru/scripts#425--naming-convention---).

b. Поле, являющееся идентификатором сущности, именуется `id`.

c. Поле, являющееся ссылкой на другую сущность, т.е. внешним ключом, именуется `<сущность>Id`. Например, сущность связана с сущностью `Company`, тогда поле должно называться `"companyId"`.

#### 4.2.3. Правила именования индексов

Название индекса состоит из следующих групп:

* префикс, представляющий собой тип индекса: обычный (idx, index)

  или уникальный (udx, unique index)
* сущность, которой этот индекс принадлежит
* поля сущности

Группы именуются в соответствии с правилами именования для данного типа идентификатора. Префикс добавляется без разделителя, поля сущности заключатся в квадратные скобки и между собой разделяются запятой.

```sql
    -- Обычный индекс
    "idxFinancialInfo[dividendYield,revenue]"

    -- Уникальный индекс
    "udxInstrument[ticker,exchange,country]"
```

#### 4.2.4. Правила именования ограничений/связей (constraint'ов)

a. Название ограничения состоит из следующих групп:

* префикс, представляющий собой тип ограничения: первичный ключ (pk, primary key)

  или внешний ключ (fk, foreign key)
* сущность, на поля которой налагается ограничение
* \[необязательное] поля сущности, на которую налагаются ограничения

Группы именуются в соответствии с правилами именования для данного типа идентификатора. Префикс добавляется без разделителя, поля сущности заключатся в квадратные скобки и между собой разделяются запятой.

b. Поле сущности для первичного ключа не указывается, т.к. оно всегда `id`.

c. Связываемая внешним ключом сущность не указывается, т.к. её описание уже представлено полем, на которое ссылкой накладывается ограничение.

```sql
    -- Первичный ключ (поле `id` сущности FinancialInfo)
    "pkFinancialInfo"

    -- Внешний ключ (связь с сущностью Instrument по первичному ключу id)
    "fkFinancialInfo[instrumentId]"
```

#### 4.2.5. Правила именования базы данных

В качестве названия базы данных должно использовать одно слово в нижнем регистре. Например, `investment`

#### 4.2.6. Правила именования схемы

В качестве названия схемы базы данных должно использовать одно слово в нижнем регистре. Например, `portfolio`. Тогда обращение к сущности внутри схемы будет выглядеть: `portfolio."PortfolioLine"`.

#### 4.2.7. Правила именования пользователей

В качестве имени пользователя должно использовать одно слово в нижнем регистре.


---

# 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://eigenspace.gitbook.io/dev-standards/db.md?ask=<question>
```

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.