Присоединюсь к прозвучавшему:
1.
Единообразно.
Все остальное формально не принципиально.
Лично я всегда использую в качестве первичного ключа поле TableName_ID. Какие преимущества я вижу в этом подходе перед другими:
1) Почти во всех связках получается условие a.table_id = b.table_id. Это дефолт, который хорошо виден глазу. Те редкие случаи, когда связка делается другим образом, зрительно выбиваются из этого ряда. Соответственно, минимизируется вероятность пропустить важную мелочь, просматривая чужой селект.
2) Аналогично, редкие случаи, выбивающиеся из общего ряда - например, ссылка в таблице на себя - также хорошо видны. Встречая поле типа table_id_parent - сразу видишь, что это не обычный pk и не обычный fk, а поле с некоторым особым смыслом. Например, в коде
1.
2.
3.
4.
create table ...
...
id_document_master integer,
id_document_detail integer
есть все основания предположить, что это две обычных ссылки на таблицы document_master и document_detail соответственно. Видя же код
1.
2.
3.
4.
create table ...
...
document_id_master integer,
document_id_detail integer
понятно, что это две ссылки на одну таблицу, и виден смысл, различие между этими ссылками.
Да, конечно, в первом случае можно использовать master_id_table и detail_id_table - но такого подхода я никогда не видел.
3) Это обеспечивает читаемый код при использовании алиасов таблиц. Я предпочитаю писать квалификаторы везде, кроме самых простых запросов; в этом случае запрос
1.
2.
3.
4.
5.
6.
7.
8.
select
a.table_a_id,
a.field1,
b.field2
from
table_a a,
table_b b
where
a.table_a_id = b.table_a_id
выглядит удобнее, нежели
1.
2.
3.
4.
5.
6.
7.
8.
select
table_a.id,
table_a.field1,
table_b.field2
from
table_a,
table_b
where
table_a.id = table_b.table_a_id
4) Нужно единообразие. Если выносить ID как префикс, точно так же нужно будет выносить и другие стандартные слова - Name, Date, Count, Qnt.... Лично с моей точки зрения они удобнее и естественнее как постфиксы. Например, если поля таблицы описывают четырех человек, у каждого из которых есть name, у троих - salary, и у двоих - hire_date, порядок полей
1.
2.
3.
4.
5.
human1_name
human1_salary
human1_hire_date
human2_name
....
представляется мне удобнее, нежели
1.
2.
3.
4.
5.
6.
7.
name_human1
name_human2
name_human3
name_human4
salary_human1
salary_human2
....
Подчеркну - это личная точка зрения. Главное - должны быть четкие правила, соблюдаемые везде в проекте. Они должны быть продуманы - так, чтобы не требовалось исключений, и проработаны достаточно, чтобы все участники проекта полностью на автомате читали код и понимали что он значит.
