Отправил в рабочий чат и понимаю, что это может пригодится и в других случаях. Поэтому вот мой гид.

Таблицы:

• название таблицы в единственном числе, кроме таблицы users (потому, что user ключевое слово в SQL), или когда строка таблицы содержит множественные значения, например stats и в каком-то свойстве хранится массив данных, но и то лучше избегать

• внутри таблицы имена полей просто имена полей без названия таблицы (не делать в таблице users_id, чтобы не было в таблице users_data поля users_users_id

• родственные таблицы начинаются с общего префикса, чтобы в списке таблиц визуально было видны таблицы рядом, например course, course_author, course_tag_rel.

• имена таблиц и полей до 30 символов

• только латинские буквы, знак _ и редко цифры в названии таблиц и полей

• не придумывать новые аббревиатуры

• для М2М связей использовать название <основная таблица>_<вторая таблица>[_rel], какая основная определяется по удобству использования, суффикс _rel использовать если так договорилась команда и есть выгоды

Столбцы:

• название в единственном числе

• id поле для поля, которое будет использоваться в других таблицах как foreign key

• ссылка на поле из других таблиц <имя таблицы>_<имя столбца>, по схеме сразу понятно кто на кого ссылается, например course_id

• индексы и sequence объекты сейчас базы данных и миграции в целом хорошо придумывают по умолчанию, если нет, то <имя таблицы>_<имя поля>[_<имя поля2>]_idx (если 3 и более, то придумать логичное обозначение одним словом) или _seq (для последовательностей)

• для boolean полей использовать префикс is_, например is_deleted

• для записей, которые подразумевают сохранение дату создания и модификации везде использовать created_at, modified_at, deleted_at...

Не делать:

• не использовать незначащие префиксы в названия таблиц, например tbl_user_data, просто user_data

• не использовать одно и то же название для таблицы и поля в ней

• camelCase или PascalCase

• не использовать uuid для id поля кроме редких случаев, когда надо скрыть количество данных в таблицах и не допустить протекания данных, но в целом uuid надо использовать в самых редких и особых случаях

• не использовать имена полей и таблиц, которые будут подразумевать двойные кавычки (как с user)

• длинные имена

Хорошие идеи:

• использовать hashid вместо UUID

• использовать хранимые процедуры (да, многие их ругают, но возьмите себя в руки и выучите базы данных, это лучшая инвестиция для программиста)

• использовать форматирование SQL кода, когда надо редактировать их руками

• стараться использовать совместимый SQL синтаксис, но не рассчитывать на то, что код будет работать с разными базами данных. Они слишком разные

Дополнительные ссылки:

• https://www.sqlstyle.guide/

Если вы хотите выучиться программированию и SQL, то записывайтесь на бесплатный курс по Python