История изменений

Чтобы делать таблицу без серийного id, нужны очень веские аргументы.

нет, наличие колонок образующих естественный PK - достаточный аргумент чтобы не добавлять еще и колонку с суррогатным PK, и просто назначить таковым имеющиеся

серийного id

даже если ключ суррогатный, то он может 1) назначаться клиентом как угодно согласно любым правилам 2) он может не нарастать 3) может быть строкой или чем угодно еще 4) если его обслуживает сиквенс, то он может быть один на несколько таблиц 5) может опосредованно иметь в основе генератор случайных чисел

идея о том что PK должен обязательно быть колонкой id c нарастающими int - это глупость очень популярная среди мудаков не включающих мозг

дополнено: более того. наличие pk id c нарастающими интами, на практике часто является попыткой тупых бракоделов обеспечить иллюзию уникальности строк, иллюзию порядка в БД, иллюзию качества данных. нередко в таких базах половина таблиц содержит строки, которые по сути своей дубликаты (числа по колонке id у них конечно же уникальны, это субд обеспечит). дубликаты - это плохо: от этого возникает путаница в организации, возникают проблемы у пользователей, ненужные трения среди разработчиков. конечно, чтобы делать нормальные таблицы - надо думать, работать, а они не хотят и не умеют, вот и тащат свой тупой нарастающий суррогатный id.

Чтобы делать таблицу без серийного id, нужны очень веские аргументы.

нет, наличие колонок образующих естественный PK - достаточный аргумент чтобы не добавлять еще и колонку с суррогатным PK, и просто назначить таковым имеющиеся

серийного id

даже если ключ суррогатный, то он может 1) назначаться клиентом как угодно согласно любым правилам 2) он может не нарастать 3) может быть строкой или чем угодно еще 4) если его обслуживает сиквенс, то он может быть один на несколько таблиц 5) может опосредованно иметь в основе генератор случайных чисел

идея о том что PK должен обязательно быть колонкой id c нарастающими int - это глупость очень популярная среди мудаков не включающих мозг