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

[ns-roxer]

1. https://github.com/go-park-mail-ru/2023_2_AdDo/tree/PK-2/database - основную дирректорию с файлами базы я просил назвать по-другому. Переименуйте, пожалуйста.
2. https://github.com/go-park-mail-ru/2023_2_AdDo/blob/PK-2/database/normalized/musicon-erd.pdf - не вижу схемы бд описанном на языке диаграмм типа plantuml или mermaidjs
3. https://github.com/go-park-mail-ru/2023_2_AdDo/blob/PK-2/database/normalized/relations.md - прошу нормально отредактировать описание ФЗ средствами mardown, читать неформатированное полотно текста очень сложно
4. Цитата из задания - Каждая таблица должна иметь краткое словесное описание в markdown. Не нашел такого в указанной ветке, необходимо добавить!
5. https://github.com/go-park-mail-ru/2023_2_AdDo/tree/PK-2/database/migrations - файлы в этой директории необходимо называть как-то содержательно, иначе абсолютно непонятно что там и зачем вобще эти файлы тут нужны.
6. https://github.com/go-park-mail-ru/2023_2_AdDo/blob/PK-2/database/migrations/migration_2.sql - это не миграция, тут нет изменений схемы данных. Необходимо вынести этот файл в другую директорию!
7. Вопрос - почему profile.id сделали типом uuid, а не serial/bigserial?
8. Все varchar(N) необходимо либо исправить на text, либо хорошо аргументировать комментарием рядом с поле, из каких соображений выбрано это ограничение!
9. https://github.com/go-park-mail-ru/2023_2_AdDo/blob/PK-2/database/migrations/migration_1.sql#L100 - либо убрать, либо раскомментировать и доработать. Для истории у вас есть git, а комментарии для пояснений, а не для хранения наработок!
10. вопрос - playlist.creating_date - вам точно достаточно хранить дату, а не точное время создания плэйлиста?

[Dmitry-Evsyukov]

1. Директория Переименована
2. Добавил в db/normalized erd-mermaid.md, erd-schema.md. Первый файл - описание таблиц на языке mermaid, второй - визуально сгенерированная диаграмма отношений
3. Отредактировано
4. Прошу прощения, описание было в ветке main, отформатировано и добавлено в ветку PK-2
5. Переименовали миграцию в db_schema.sql
6. Вынесено в отдельную директорию fill_data
7. Это безопаснее, так как у нас пренебрежимо маленькая вероятность, что случайно сгенерированный uuid будет совпадать с другим, а числа могут кончиться, так как даже при неудачном запросе к базе счетчик инкрементируется. Также проще обеспечивать конкурентность к базе, ведь при вставках не нужно инкрементировать общий счетчик. Наконец, так мы не выдаем информацию о количестве пользователей в нашей базе и порядке их вставки.
8. Комментарии добавлены. Отдельно стоит сказать, что если строки, которые мы храним невелики, то varchar может оказаться эффективнее с точки использования памяти. Также varchar позволит нам построить индексы по строковым полям и обеспечить более быстрый поиск кортежей в базе. Наконец, это ограничение, которое не позволит пользователям создавать слишком длинные названия плейлистов или придумать очень длинные имена для своих учетных записей. В перспективе это позволит тратить меньше памяти.
9. Убран комментарий
10. Решено хранить timestamptz, про который вы говорили на лекции. В связи с этим изменен атрибут и его описание в relations.md

[ns-roxer]

Про varchar:

• 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.

• для ограничения длины можно использовать text + check constraint
• "что если строки, которые мы храним невелики, то varchar может оказаться эффективнее с точки использования памяти" - докажите! На сколько мне известно - не может никак varchar быть эффективнее по памяти, чем text, так как они хранятся в одинаковых сишных структурах, только varchar(N) расходует дополнительные ресурсы на проверку длины, а text без check constraint - нет.
• https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_varchar.28n.29_by_default - вот официальная рекоммендация разработчиков СУБД
• "Также varchar позволит нам построить индексы по строковым полям и обеспечить более быстрый поиск кортежей в базе" - а text разве не позволит? Я на лекции про индексы примеры с функциональными индексами и "text pattern ops" зря что ли делал https://mailcourses.github.io/technopark-dbms-lectures/05/#60?