Поля в базе. Какой синтаксис лучше.

[Slastik]

Поля в базе. Какой синтаксис лучше.

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

Собственно вопрос касается в основном primary полей идетификаторов.


Я вижу три варианта названия таких полей (предположим что у нас таблица с пользователями)

1. id
2. user_id
3. uid


Вариант 1. мне видится не очень читабельным, к примеру если я получаю выборку из базы в переменную $result, то $result['id'] не говорящая переменная.

Вариант 2. наиболее читабелен, но если идентификатор используется часто, то становится излишним такое длинное слово как user

Вариант 3. на первый взгляд не понятно что значит uid, но с другой стороны, когда он часто используется то uid уже вполне читабельно. Проблема в таком подходе что если таблиц много, то первые буквы таблицы часто повторяются и приходится делать уже 4ех буквенное название, например prid, а это уже плохо читается.

Хотел бы услышать ваше мнение и возможно еще какие то варианты исходя из личного опыта.

 

[jer]

лично я делаю idUser, если это внешний ключ, и id если первичный

 

[Духовность™]

давно следую правилу:

идентификаторов типа id или text вообще не держу.

Вот, таблица пользователей:

id_user
user_name
user_lastname
user_*

новости:

id_news
news_header
news_text
news_*

При составлении больших запросов это читается лучше. Т.е. любой ид начинается с префикса id_, любое другое поле начинается с префикса сущности.

 

[Фанат]

при составлении больших запросов можно (и нужно) писать префикс таблицы -
news.header
user.name

а в остальных случаях это просто ненужный бессмысленный довесок

 

[Духовность™]

ага, а потом мы забываем дописать префикс таблицы и гадаем, к какой именно таблице относится поле с абстрактным именем id.

 

[Фанат]

для забывчивых да - так будет лучше =)

 

[Духовность™]

ааааа! ***** со мной согласился!!!! Пойду напьюсь ща!!!

 

[Slastik]

*****

то есть таблицу пользователей ты бы сделал:

id
name
age

?

 

[Фанат]

Да, я так и делаю.

-~{}~ 16.04.08 17:58:

$result['id'] не говорящая переменная.

зато позволяет писать грязный, но чудовищно удобный код, когда основываясь на таких вот соглашениях (что идентификатор всегда имеет фиксирвоанное имя) можно практически без изменений адаптировать огромные куски кода.

 

[berkut]

а в остальных случаях это просто ненужный бессмысленный довесок

ничего бессмысленного. когда джоинится таблицы с одинаковыми полями:
SELECT user.name, car.name -> SELECT user.*, car.*
вот чтобы не следить за именами всех полей и не делать AS они и хороши префиксы.

 

[Фанат]

дубль два.
какая разница - писать car_id или car.id?

 

[berkut]

дубль два.
какая разница - писать car_id или car.id?

пля. SELECT car.id, user.id FROM car INNER JOIN user ON .....
что в итоге получаем?

-~{}~ 16.04.08 19:29:

получаем 2 поля с именами id, id_1

-~{}~ 16.04.08 19:33:

а делаем SELECT car.car_id, user.user_id FROM car INNER JOIN user ON .....
получаем car_id, user_id - с этим уже можно нормально работать.

 

[Фанат]

а, ну тогда да. кому лень писать алиасы - тот может писать заранее

 

[Slastik]

Автор оригинала: berkut
пля. SELECT car.id, user.id FROM car INNER JOIN user ON .....
что в итоге получаем?

-~{}~ 16.04.08 19:29:

получаем 2 поля с именами id, id_1

-~{}~ 16.04.08 19:33:

а делаем SELECT car.car_id, user.user_id FROM car INNER JOIN user ON .....
получаем car_id, user_id - с этим уже можно нормально работать.

а если таблица называется job_adverts_fields_texts

вы и поле назовете restate_adverts_fields_texts_id?

 

[С.]

$result['id'] не говорящая переменная.

А ты пиши $user['id'] и будет тебе говорящая переменная.

 

[Beavis]

я называю всегда id_*
в ON-условиях JOIN'a понятнее всё-таки когда написано
[SQL]
ON c.id_catalog = p.id_catalog
[/SQL]
(т.е. когда приравниваемый первичный и внешний ключ имеют одинаковые имена)
чем
[SQL]
ON c.id = p.catalog_id
[/SQL]
или типа того

 

[StUV]

имхо, тоже удобнее id_*
ибо в запросах с таблицами с внешними ключами читабельнее
tbl_some.id_some, tbl_some.id_other
при этом в tbl_other тоже id_other
так что это лишнее описание - не лишнее =)

 

[weregod]

primary - id
внешние - id_пипен...

однозначно, оргументы за уже высказанны

 

[Beavis]

ни одного аргумента "за", кроме того что так делает фанат я тут не вижу)

 

[ONK]

Считаю правильным использование такого приципа:

Поля таблиц начинаются с абривиатуры от имени таблицы, далее идёт имя сущности поля, далее, в случае ключей добавляю постфикс _id

Само имя сущности поля стараюсь делать как можно короче, без лишних слов из серии (user_to_rights_group_id).

group_items_rel{
gir_record_id,
gir_item_id,
gir_group_id,
gir_creator_id,
gir_type,
gir_date
}

Как показывает практика, в SQL запросах по префиксу имени поля уверенно идентифицируются таблицы в проекте с сотнями таблиц. (Подразумевается, что человек знаком с проектом.)
А общие правила наименования и короткие имена сущностей позволяют, во многих случаях, писать SQL запросы не смотря документацию по структуре таблиц.