У меня есть такое соглашение, что в любой таблице есть поле id (первичный ключ), а любая ссылка на таблицу sometable имеет суффикс sometable_id (чаще всего так и называется, иногда бывает надо несколько ссылок, тогда меняется префикс).
Таким образом у суффикса _id есть однозначное семантическое значение — это поле, указывающие на какую-то таблицу в текущей БД.
При взаимодействии с внешними сервисами часто используются их идентификаторы, которые нужно хранить в базе. И в API внешних сервисов они обычно называются id. И порой по формату совпадают с идентификаторами локальной базы, хотя никуда и не указывают. Вроде возникает логичное стремление называть его some_entity_id. Но это немного путает.
Хочется придумать замену этому суффиксу _id для внешних ключей.
Пока придумалось такое: _external_id — семантически почти идеально, но слишком длинно; _code — остановился пока на таком варианте, но не совсем доволен, всё-таки код и идентификатор это не всегда одно и то же; что-то вроде _eid, _exid, _extid — вариация на тему сокращения первого варианта.
Как бы вы на этот вопрос ответили, если бы вас охватил внезапный приступ перфекционизма?
Еще мысли вслух со стороны: e, ex и ext могут быть восприняты как extra или extended. То есть если кто-то будет смотреть на это свежим взглядом не зная конвенции, может возникнуть путаница.
Здравствуйте, vsb, Вы писали:
vsb>Хочется придумать замену этому суффиксу _id для внешних ключей. vsb>Пока придумалось такое: _external_id — семантически почти идеально, но слишком длинно;
Во-первых, в *_external_id суффикс по-прежнему id. Так это читается.
Во-вторых, мне сама идея заменить один суффикс на другой не кажется правильной. Если _id это всегда ссылка и всегда на таблицу с именем, предшествующим _id, то суффикс имеет смысл, всё ок. Но для внешних ключей, как и указано, нет никакой жёсткой схемы, что тогда там делает суффикс? Там тот факт, что это внешний идентификатор — просто часть назначения поля, поэтому я бы так и писал: id_for_yet_another_cloud_service (оформление, например, сокращения, добавить по вкусу).
Иными словами, я бы подумал, заслуживает ли вообще такой кейс, как хранение внешних идентификаторов своего суффикса.
Здравствуйте, Shtole, Вы писали:
S>Иными словами, я бы подумал, заслуживает ли вообще такой кейс, как хранение внешних идентификаторов своего суффикса.
Я наверное не совсем понятно выразился. Я не хочу хранить внешние идентификаторы с определённым суффиксом. Просто у внешних идентификаторов имя id и его его хранить как есть, то возникает такая вот коллизия. Поэтому конкретно этот идентификатор (который часто встречается) хочется переименовать, но в идеале так, чтобы оставалось понятно, какое у него примерно было исходное имя.
Переносить название атрибута в начало имени мне не очень хочется, как-то привык уже, что всегда в имени идёт сначала общее, потом частное, это удобно во многих отношениях, но спасибо за идею, ещё подумаю.
Пока больше всего понравился _rid (remote id), предварительно на этом варианте остановлюсь, нравится больше, чем мой вариант с _code.
Re[3]: name convention для внешних идентификаторов
Здравствуйте, vsb, Вы писали:
vsb>Я не хочу хранить внешние идентификаторы с определённым суффиксом.
... vsb>Пока больше всего понравился _rid (remote id)
Я усматриваю между этими двумя предложениями некое противоречие
Всё-таки, _rid — это суффикс, как ни крути. Допустим, нужно хранить логин от Скайпа и схема id_for_skype не нравится (нужно общее впереди частного). Но тогда логично было бы назвать поле skype_id, а не skype_rid, правильно? Иначе я, если бы открыл такую БД и увидел такое поле, полез бы в документацию по Скайпу, искать, что такое rid. Если заменить rid на fid, лучше не станет. А на самом деле, даже если записать целиком, skype_remote_id или skype_external_id и не иметь никаких правил про суффиксы (т.е., идеальный случай), я, опять же, буду долго чесать в затылке, соображая, что за remote id такой (а это, на самом деле, просто id).
Получается, настоящая проблема в том, что нужно отличать id как суффикс и id как слово.
В языках с регистровой чувствительностью, типа сей, одно время было принято слова отделять регистром, а суффиксы и префиксы — подчёркиванием (m_MyWindow). Но для SQL это не вариант. Поэтому, лично у меня вариантов два:
1. Если неимоверно хочется избежать коллизий, придумать схему обозначения суффиксов. Например, _id — это слово, а __id — суффикс.
2. Забить. Так и писать skype_id. По контексту (отсутствию таблицы skype) легко догадаться, что это слово. Я бы выбрал его, в последнее время стараюсь не мудрить и не жертвовать читаемостью в угоду жёстким схемам. (Всякие BEM, например, для меня вообще выглядят как for robots, by robots ).
3 (бонус). Заменять id (как слово) на login, user и другие подходящие слова (можно даже userid одним словом). Не зная, о каких внешних сервисах идёт речь, нельзя сказать, насколько это уместно.
Здравствуйте, Dym On, Вы писали:
DO> ·>Если я правильно помню терминологию это называется natural key. DO> Не, описываемый чаще всего суррогатный ключ.
По-моему ты меня запутываешь, я всё правильно говорю.
С т.з. системы разрабатываемой топикстартером — это натуральный ключ (A natural key is a type of unique key in a database formed of attributes that exist and are used in the external world outside the database).
Суррогатным ключом являются его колонки id (A surrogate key in a database is a unique identifier for either an entity in the modeled world or an object in the database).
