# Использование UTF-8
> Все новые таблицы создавать в utf-8 (utf8mb4)

**За**
- Не нужно перекодировать туда сюда, не нужно декодить в htmlentities и обратно, не нужны разные настройки и нет проблем с тестами [#n52](https://repetitors.info/admin/aforum/?t=149780#n52)
- Апи, софт и веб-инструменты почти не умеют работать с htmlentities по умолчанию [#47](https://repetitors.info/admin/aforum/?t=149780#n47)
- Полноценная возможность для i18n [#9](https://repetitors.info/admin/aforum/?t=149780#n9)
- Все больше в текстовых данных встречаются символы не из 1251 [#9](https://repetitors.info/admin/aforum/?t=149780#n9)
- Мир движется к юникоду ([стата от w3c](https://w3techs.com/technologies/cross/character_encoding/ranking)) и хочется начать делать шаги в эту сторону [#52](https://repetitors.info/admin/aforum/?t=149780#n52)

**Против**
- Занимают в два раза больше места (ASCII и англосаксонские занимают 1 байт) [#2](https://repetitors.info/admin/aforum/?t=149780#n2)
- Умеем работать с utf через htmlentities [#19](https://repetitors.info/admin/aforum/?t=149780#n19)
- Сам utf-8 не до конца стандарт (хотя есть [RFC](https://tools.ietf.org/html/rfc3629)) [#59](https://repetitors.info/admin/aforum/?t=149780#n59)
- Нет продуктовых задач в которых нужен utf-8. htmlentities позволяет решать все что нужно [#59](https://repetitors.info/admin/aforum/?t=149780#n59)
- Нужно переходить везде и разом - это дорого, сложно и нецелесообразно [#59](https://repetitors.info/admin/aforum/?t=149780#n59)

**Предлагаемое решение**
Мое мнение - нужно переходить.
Utf-8 вполне себе стандарт - в моей картине мира RFC это весомый документ. Но делать это постепенно - новые модули, сущности создавать в utf, старые места в коде постепенно переделывать на utf.
Это не быстрый процесс, но в перспективе мы упростим разработку и код убрав все места с конвертацией и декодом (такие проблемы периодически возникают, тормозят разработку и генерят ошибки), сделаем работу с современным api, софтом и веб инструментами нормальным сразу "из коробки".
Так же думаю, что локализация не за горами - и было бы суперудобно подготовить для этого и код и базу в спокойном режиме.

# Использование int в качестве идентификатора
> В качестве идентификатора используй int ... они занимают намного меньше места и работают быстрее. Пример: Идентификатор препа ShmalNM, VulVa — не делай так!

**За**
- Занимают меньше места (разные схемы, аналитика, логи) [#10](https://repetitors.info/admin/aforum/?t=149780#n10)
- Работают быстрее [#10](https://repetitors.info/admin/aforum/?t=149780#n10)
- Так как есть сущности, которые работают с разными таблицами, то хочется, чтобы id были везде одного типа [#48](https://repetitors.info/admin/aforum/?t=149780#n48)

**Против**
- Не удобно просматривать глазами

**Предлагаемое решение**
В новых структурах данных не использовать подход со строками в качестве идентификаторов.
Старые структуры плавно рефакторить, если это мешает созданию новых структур с числовыми идентификаторами.

# Именование таблиц и полей
> Названия — слова английского языка

Это самый комментогенный кусок. Попробую выписать два обсуждаемых варианта и рассмотреть их возможности:

## Имена полей интуитивно понятны
**Плюсы**
- Суть ясна из названия почти сразу - не нужно смотреть соседний код (не все это могут) или спрашивать у кого-то
- Новые люди смогут быстрее понимать код и сущности в БД
- К такому варианту привык мозг/глаз так как это общепринятый подход

**Минусы**
- Занимают много места на экране
- Сложно(?) придумать "интуитивно понятные" названия нашим узкоспециальным специфическим терминам

## Имена собственные, конкретные короткие уникальные термины, желательно одинаковой длины в одном смысловом куске

**Плюсы**
- Точная идентификация сущности
- Просто искать в коде
- Занимают мало места в коде, на экране, в таблице
- Можно оперировать в устной и письменной речи

**Минусы**
- Мало документации и она по всему форуму лежит
- Долгое погружение в код, задачи и обсуждения
- Сложно придумывать названия в этой парадигме в большой команде
- Есть какой-то глобальный набор вещей и названий которые "надо знать". Но что это за сущности, классы, функции и понятия - не ясно.
- Сущности создаются каждый день и невозможно держать их все в голове, а спотыкаться о каждую и искать доки очень долго

**Предлагаемое решение**
Тут можно долго спорить над каждым вариантом.
Но мне кажется, что подход который мы продвигаем в этой доке более привычен.
Это очень важный момент - мы, как разработчики, читаем не только наш код, но и код различных библиотек и решений.
И там, в подавляющем большинстве случаев, используется предлагаемый подход к наименованию.
Обучение новому диалекту (а это именно так - приходится запоминать новые слова) очень замедляет погружение в код и прблемы.
Сложно начать разговаривать на одном языке со всеми - я, например, после 7 месяцев работы не могу сказать, что все термины и обозначения понимаю.
Каждый раз расшифровывать или искать доку - не очень приятное занятие. Особенно если доки нет. И получается, что наши дорогие (в любом смысле) разработчики вынуждены тратить время на постоянное выяснение терминов.
Споры о длине на экране и возможности выравнивания - это похоже на вкусовщину. У всех давно современные ноутбуки и большие мониторы. Да и IDE умеют выравнивать все автоматически.
Перевешивает ли это плюсы от точной идентификации сущности и простоты поиска в коде?
Мое мнение -- да.