Замечания к СРС 1 по курсу СУБД

[ns-roxer]

1. Миграции должны располагаться на уровень выше - db/migrations
2. https://github.com/go-park-mail-ru/2023_2_Chaihona_No.1/blob/dev/db/normalized/er.jpg - схема отличная, но описание на plantuml или mermaidjs - тоже обязательное требование. Необходимо, чтобы er диаграмма таблиц была версионируемой, а картинка - это лишь приятный бонус.
3. https://github.com/go-park-mail-ru/2023_2_Chaihona_No.1/blob/dev/db/normalized/relations.md?plain=1#L77 - к кому вопрос?
4. https://github.com/go-park-mail-ru/2023_2_Chaihona_No.1/blob/dev/db/normalized/migrations/create_tables.sql - приведите в порядок форматирование пожалуйста. С переносами в описаниях constraint вы явно перестарались, читать трудно. FOREIGN KEY ( user_id ) пробелы внутри круглых скобок не нужны
5. creation_date timestamp - название атрибута противоречит содержимому. Приведите название к created_at и updated_at. Нет смысла называть поле last_updated_at, потому что какое еще изменение кроме последнего может подразумеваться по-умолчанию?

[M0rdovorot]

Все исправили

[ns-roxer]

Прошу прощения, если в прошлый раз пропустил, но использование varchar(N) у меня вызвает вопросы.

Либо аргументируйте, либо меняйте на text, если хотите жестко ограничивать длину, то можно использовать text + check constraint, иначе мне нужна железная аргументация.

Что почитать:

• https://www.postgresql.org/docs/current/datatype-character.html - цитата:

  There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead.

• https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_varchar.28n.29_by_default - вот официальная рекоммендация разработчиков СУБД