Изменения в БД ДЗ1

[SmileyTheSmile]

Файл с отношениями

• Не нужно писать про нормальные формы в каждой таблице, НФ - это свойства БД, а не отдельных таблиц. Вынесите это в отдельную главу, чтобы не повторять один и тот же текст много раз. Упомяните только какие-то уникальные случаи и исключения, если такие есть.
• Ограничение not_negative_price удостоверяется(?). Не уверен будут ли придираться к грамматике, но вам на заметку.
• ФЗ стоит каждую записывать с новой строки, они сливаются вместе.
• Email пользователя и другия уникальные поля, которые при этом не являются первичными ключами должны быть помечены как Unique key, они не являются первичными ключами.
• В таблице юзера: { id } -> email, password_hash { email } -> id, password_hash { id, email } -> password_hash id здесь - первичный ключ, поэтому остальные поля уже зависят от него, поэтому { id, email } -> password_hash не имеет смысла упоминать. В остальных таблицах также, как например { phone } -> id, user_id, name, surname, regtime, city_id, verified, avatar_url. Если phone у вас - уникальное поле, то это Unique key, не первичный.
• В таблице order указывается много данных о заказчике, почему? Это должно получаться из других таблиц, иначе НФ тут нет. Если тут какая-то особенность, поясните.
• Не совсем понял поле category.translation.
• Возможно имеет смысл из таблицы status сделать enum.
• У соединяющих таблиц ManyToMany не нужен id - у них PK - комбинация полей id таблиц, с которыми они связаны. Во View это user_id и advert_id. Cart, favourite, всё такое к этому относится.
• Review - это не сводная таблица, а таблица сущности Review.
• Для всех полей типа "дата создания" нужно решить нужно ли вам хранить тайм зону в каждой строке. Если да, оставьте now(), если нет, подойдет CURRENT_TIMESTAMP.
• Пояснения в таблице Subscription непонятные.
• Стоит по-подробнее написать описание таблицы View. Я понял что вы хотите сделать, но на первый взгляд неочевидно.

Схема

• Я бы вынес изображения из всех таблиц в одну image, а не использовал её только для заказов.
• В таблицах не указаны ключи PK, FK, UK.

Миграции

• Миграции должны быть в отдельных файлах на каждую таблицу. Для их генерации в GO есть разные утилиты, в задании вам рекомендуется пользоваться tern. Она создаёт файлы миграций, вы туда засовываете SQL код и потом можете их применять к своей БД одной командой.
• Советую попробовать сделать миграцию для схемы (public). Возможно сохранит вам немного нервов, если получится.
• Можете создавать таблицы и ограничения и т.п. в PGAdmin-e и копировать скрипты создания в миграции. Просто на заметку, это как вам удобно.
• Уберите по возможности кавычки из названий таблиц, могут придраться.
• Я бы задавал PK и FK как отдельные constraint-ы, например: CONSTRAINT workspace_user_id_fkey FOREIGN KEY (id_creator) REFERENCES public.user (id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION NOT VALID )
• Есть смысл не везде использовать bigint, а где нужно просто int или smallint.

[SmileyTheSmile]

Маркдаун

• Стоит переименовать таблицу image в advert_image, чтобы не было конфузов.
• Почему в остальных случаях уникальных ключей они определяют все поля в таблице, кроме id, а здесь только id?
• А здесь уникальность вместе вообще ничего не определяет
• complaint а не complain пожалейте моё английское сердце

Схема

• Не везде убрали id у смежных таблиц.
• Если вы ключи напишете не в скобках, а через пробел, они пойдут отдельным столбиком, будет чище. Но и так сойдет.

Миграции

• Для GO есть модули tern и migrate ( помимо прочих, но в задании вам указано использовать их), они нужны, чтобы применять миграции к БД. Там вы в командной строке создаете файл с миграцией, в него пишете create и drop скрипты. Так делаете для всех нужных вам миграций, в правильном порядке, чтобы при создании таблицы с ссылкой на таблицу пользователя, например, не было ошибки, что вы обращаетесь к несуществующей таблице. Если вы всё сделаете правильно, вы сможете одной командой обновлять вашу БД или создавать с нуля.
• Технически, пересоздание БД с нуля каждый раз, когда у вас какие-то изменения - плохая практика, представьте, что у вас есть там уже огромная куча данных пользовательских. Для этого нужны миграции - если вы хотите обновить таблицу, вы добавляете новый update скрипт, например, и прогоняете одну команду, обновляя БД. У этого есть свои минусы, так что на тестовых стадиях можете пересоздавать БД, но учтите зачем миграции нужны, вообще. Вам нужно по заданию сделать их либо через tern, либо через migrate.
• Нужно убрать кавычки из названий таблиц, если названия - не ключевые слова.
• Пустой файл status.