Ребята, всем привет! - БД в третьей нормальной форме - в БД

все связи между таблицами реализованы внешними ключами
- все индексы в БД созданы по результатам частотного анализа эксплуатационных испытаний
- схема БД исключает дублирование логических сущностей
- все пароли и уязвимые информации должны быть хэшированы
- сохранять дату/время в UTC и конвертировать в желаемый часовой пояс на уровне презентации
- изменения в БД через миграцию

что еще сюда можно добавить ? Это типа как подсказка для разрабов( мы на аутсорс отдаем проект)

Это и так все знают, не студентам же отдаете, ИМХО надо идти куда то в сторону покрытия предметной области

>Это и так все знают ох, если бы

всех не читал, но отмечу. По радужным таблицам многие хеши, например, мд5 до 9 символов ломается за минуты. Сам качал, пробовал :) То есть нужна соль. Также отмечу. Вот прям упереться в третью нормальную форму, такое себе решение. То есть на бумаге выглядит красиво, а по факту в живом коде будет тихий ужас, сам заказчик взвоет.

А что такое логическая сущность и действительно ли надо 3НФ? Какие конечные задачи у системы хранения?

>- БД в третьей нормальной форме Куча БД этому не удовлетворяют, поскольку активно работают с json, что сразу выкидывает их из первой нормальной формы. Избавиться неполучается, поскольку только так в постгресе можно локализовать вместе кучу всяких данных.

Все обращения к БД с параметрами должны исключать возможность ошыбочного превращения сервером этих параметров в выражэния (SQL injection).

Думаю орм исключает сразу вот это?

Средне-нормальный ОРМ вообще ничего не исключает.

Максимум серверных функцый должно быть реализовано на SQL. Применение PL/pgSQL или других императивных языков должно быть оправдано какой-то особой необходимостью. (Тормозит он страшно по сравнению с SQL).

Про работу DBA тут ни слова не сказано. Это будет не self-hosted какой-то проект, т.е. DBA будут отдельно, да?

а что подразумевается под ДБА? я не до конца понимаю суть работы ДБА если честно

>- схема БД исключает дублирование логических сущностей Опять довольно жёстко. Всё понятно, да -- но часто как замену несуществующим межтабличным индэксам или агрегатным индэксам приходится много чего дублировать.

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

например, сегодня у меня от сбоя вылетела программа. Опытные дба с чата посоветовали посмотреть лог. Я посмотрел, там явно видно, что ошибка в диске. Также "эти же" опытные дба советовали нанять себя, чтобы они мне базу оптимизировали. Но тут мимо, я бедный и экономный. а ваще дба для кодеров нужны только чтобы смотреть план запроса.

а что если допустить дублирование и до 2нф только сделать ?

Это если в общем, в деталях там много проблем решается вроде индивидуальной скорости отдельных компонент и резервов по всему -- по месту, по throughput, по response time. Плюс -- в мониторинге куча мелких особенностей, которые позволяют предупредить катастрофические изменения.

Я бы советовал поднять до 5нф и потребовать весомого письменного обоснования для отступлений.

Нет, не исключает. Как минимум всегда есть возможность через орм запустить sql-сниппет какой-нибудь

Ещё, в качестве хорошэго совета -- не использовать char(n), varchar(n), varchar -- только text и check constraint. Помогает когда надо внезапно расшырить поле как минимум. Плюс, в 14 слегка поломали varchar для некоторых индэксов. Скоро починят, но...