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

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

 Marc B03 мая 2012 г., 20:28
something_id избыточно, когда вы можете использоватьtable.id везде ... если только вы не введете внешний ключ.
 niico27 мая 2016 г., 13:29
проблема внешнего ключа является причиной, по которой "ID" может сбивать с толку - потому что тогда вам нужно создать отношения с & quot; somethingID & quot; в другой таблице; Вы создаете отношения на полях с разными именами.
 erikkallen03 мая 2012 г., 22:35
Мне всегда было интересно, что люди думают о плюсах и минусах подходов

Ответы на вопрос(5)

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

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

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

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

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

Решение Вопроса

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

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

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

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

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

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

Ваш ответ на вопрос