Вопрос по mysql, sql – Именование первичных ключей «id» вместо «thing_id »в SQL [закрыто]

6

Мне интересно, как лучше именовать первичные / уникальные ключи в базе данных со многими таблицами. Если вы всегда просто вызываете первичный ключ каждой таблицыid или можно не иметьid поле в каждой таблице и просто назовите каждый из нихsomething1_id, something2_id, так далее?

something_id избыточно, когда вы можете использоватьtable.id везде ... если только вы не введете внешний ключ. Marc B
Мне всегда было интересно, что люди думают о плюсах и минусах подходов erikkallen
проблема внешнего ключа является причиной, по которой "ID" может сбивать с толку - потому что тогда вам нужно создать отношения с & quot; somethingID & quot; в другой таблице; Вы создаете отношения на полях с разными именами. niico

Ваш Ответ

5   ответов
-2

ь (что-то) Id (например,user_id) для обычных таблиц. Так для столаcustomer_company_relation_metadata использованиеccm_id, Но его хорошо использоватьid также

Очень длинные имена могут быть сокращены, возможно. Я бы не стал использовать его для пользователя (что это за 2 буквы, если вы много платите за удобочитаемость?). Это действительно отчасти ваше предпочтение, но сокращать до сокращенно просто неправильно (я бы не хотел поддерживать подобный код). PS: Если у вас есть достойный редактор, даже длинные имена не должны иметь значения.
@Styxxy Да, пользователь - плохой пример. Я отредактирую это для лучшего. И это не относится ко всему коду, только к SQL. Мы полностью вместе, что плохо для других вещей.
@Styxxy Я обнаружил, что они являются наиболее полезным способом иметь длинные имена столбцов (которые раздражают при более длинных запросах) и использоватьuser.id все время. Но это, конечно, дело вкуса.
Пожалуйста, не используйте сокращения в этом контексте, это только запутывает ваш код и становится менее читаемым для новых членов вашей команды / кода (и даже вас самих после перерыва). Хороший материал для чтения:programmers.stackexchange.com/a/24083
5

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

да, спасибо, я согласен, этот вопрос возник, поскольку я писал все больше и больше СОЕДИНЕНИЙ ... tim peterson
@bfrohs: Да, я согласен, что включение имени таблицы в имя столбца идентификатора требует немного больше ввода.
Преимущество для обоих при выполнении объединений. я предпочитаюid для имени столбца, так как я буду перечислять имена таблиц перед столбцами вall присоединяется в любом случае, такtablename_id или что-то подобное просто лишняя, ненужная специфика.
8

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

15

Whatever you do, pick one or the other and stick to that standard.  Есть плюсы и минусы для каждого.

я предпочитаюSomethingID но другие люди предпочитают простоID, В системе, с которой я работаю, существует более тысячи таблиц, и наличие одинаковых имен PK и FK облегчает работу.

Абсолютно худшее - это БД, которые используют более одного соглашения об именах. Я работал над системой, которая использовала 4 различных соглашения об именах для суррогатных ПК.
привет КМ, спасибо. Так что, пока не существует явно лучшего способа, я думаю, что я буду придерживатьсяsomethingID. tim peterson
@tim peterson, все зависит от того, как вы используете SQL и что работает для вас. Ключевым моментом запроса является быстрое получение информации, и имя столбца на это не повлияет, использование индекса будет.
1

id это просто удобное соглашение - вы можете вызывать поле как угодно, если вы объявите его как ключевое поле.

Префикс ID в соответствующем контексте может быть полезен, когда речь идет о чтении и написании кода, и особенно улучшает читабельность при объединении данных из нескольких таблиц и внешних ключей.

@Styxxy Да, пользователь - плохой пример. Я отредактирую это для лучшего. И это не относится ко всему коду, только к SQL. Мы полностью вместе, что плохо для других вещей.
Пожалуйста, не используйте сокращения в этом контексте, это только запутывает ваш код и становится менее читаемым для новых членов вашей команды / кода (и даже вас самих после перерыва). Хороший материал для чтения:programmers.stackexchange.com/a/24083
(Just a thought because your answer caught my eye and I was thinking about programming to an interface.) Правда, и я согласен, ноid подход лучше переводит записи таблицы в объекты, особенно если у вас есть абстрактный суперкласс сid имущество. Если вы делаете то, что вы предлагаете (что я тоже делаю), то вы также должны управлять различнымиblahId поля и свойства при сопоставлении записей таблицы с объектами. Это было бы верно для внешних ключей, которые в любом случае переводятся в свойства объекта, но, по крайней мере, абстрактный суперкласс мог бы просто иметь простое свойство с именемid.
@Styxxy Я обнаружил, что они являются наиболее полезным способом иметь длинные имена столбцов (которые раздражают при более длинных запросах) и использоватьuser.id все время. Но это, конечно, дело вкуса.

Похожие вопросы