Вы предпочитаете многословное наименование, когда дело доходит до столбцов базы данных?

Question

Что вы предпочитаете?

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

CREATE TABLE Products 
(
    ProductID int NOT NULL IDENTITY(1,1) PRIMARY KEY, 
    CategoryID int NOT NULL FOREIGN KEY REFERENCES Categories(CategoryID), 
    ProductName varchar(200) NOT NULL 
) 

используя явное присвоение имен для столбцов (например продукта Имя, Продукт ID), или что-то вроде:

CREATE TABLE Products 
(
    ID int NOT NULL IDENTITY(1,1) PRIMARY KEY, 
    CategoryID int NOT NULL FOREIGN KEY REFERENCES Categories(ID), 
    Name varchar(200) NOT NULL 
) 

Из того, что я мы видели, что соглашение в мире .NET должно быть явным - образцы, как правило, используют первый пример, в то время как открытый источник и мир RoR предпочитают второй. Лично я считаю, первый легче читать и понимать, на первый взгляд: select p.ProductID, p.ProductName, c.CategoryName from Categories c inner join Products p on c.CategoryID = p.CategoryID кажется намного более естественным для меня, чем select p.ID AS ProductID, p.Name AS ProductName, c.Name AS CategoryName from Categories c inner join Products p on c.ID = p.CategoryID

Я полагаю, что, учитывая зачаточное пример, который я при условии, что это не имеет большого значения, но как о том, когда вы имеете дело с большим количеством данных и таблиц? Я бы все же нашел первый пример лучше второго, хотя, возможно, некоторые комбинации двух могли бы заглянуть в (<Table>ID для ID, но только Name за имя?). Очевидно, что по существующему проекту вы должны следовать уже принятым конвенциям, но как насчет новой разработки?

Каковы ваши предпочтения?

Answer 1

Имя таблицы уже дает контекст. Не нужно указывать имена столбцов с ним. При объединении таблиц используйте синтаксис table.column.

Answer 2

Я фанат варианта 3:

CREATE TABLE Products 
(
    ProductId int NOT NULL IDENTITY(1,1) PRIMARY KEY, 
    CategoryId int NOT NULL FOREIGN KEY REFERENCES Categories(CategoryId), 
    Name varchar(200) NOT NULL 
) 

Таким образом, первичный ключ является единственной колонкой, чтобы получить имя таблицы в качестве префикса - ИМХО это делает его легче увидеть, когда присоединиться пошли неправильно. Опять же, мне также нравится использовать GUID для первичных ключей, если есть какая-либо возможность справиться с ситуацией репликации слияния в любой момент в будущем ...

Answer 3

Одна из школ мысли состоит в том, что имя столбца должно представлять собой однодоменное пространство в базе данных. Например, название продукта отличается от названия компании. Один может быть длиннее другого и т. Д. В этом отношении вы должны использовать первый метод, поскольку он различает эти два.

С другой стороны, я согласен в определенной степени с логикой Think Before Coding. Я всегда использую синтаксис table.column, поэтому контекст должен быть ясным.

Использование более подробных имен столбцов обычно позволяет избежать конфликтов с зарезервированными словами.

Опять же, это может быть довольно избыточным, если каждый столбец в вашей таблице продуктов ProductXxxx.

Другими словами, у меня нет абсолютного предпочтения, но я больше склоняюсь к подробному соглашению об именах.

Answer 4

Я предпочитаю придерживаться короткой версии «ID». Легко понять и следовать соглашению, что идентификатор записи для таблицы будет называться «ID», и он будет ссылаться на свою «собственную» таблицу, а не на что-то другое (хотя иногда нет необходимости в «собственном» идентификаторе в некоторые таблицы, такие как отображения).

Еще один результат, который он дает, заключается в том, что всякий раз, когда вы пишете запрос, вам не нужно думать и помнить точное имя столбца. Вы знаете, что, как только имеет смысл, чтобы таблица имела идентификатор записи, на нее можно ссылаться на «ID».

Это упрощает ситуацию.

Answer 5

Обычно я даю каждой таблице уникальный префикс. Таким образом, ваш пример будет примерно таким, как

CREATE TABLE Products 
(
    PROD_ID int NOT NULL IDENTITY(1,1) PRIMARY KEY, 
    PROD_CAT_ID int NOT NULL FOREIGN KEY REFERENCES Categories(CAT_ID), 
    PROD_NAME varchar(200) NOT NULL 
) 

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

Однако в последнее время я начинаю с того, что (2) может быть лучше, потому что это ближе к соглашениям об именах, которые я использую при написании кода (C# в моем случае).

Answer 6

Я придерживаюсь как можно короче имен. Люди, приписывающие имя таблицы в каждом столбце, делают меня жестоким. PERSON.first_name, а не PERSON.person_first_name. Мы знаем его человека, его персональный стол ... что еще это будет?

Единственный раз, когда я иду против этого правила, для идентификационных номеров, например: PERSON.personID.

Это правило, приносящее извинения Эйнштейну; быть настолько подробным, насколько это необходимо, но не более подробным.

Answer 7

Я предпочитаю UID, GID, Pid, ​​WID, крышку и т.д ..

Answer 8

ID ужасно запутанный, когда у вас есть много соединений. Я предпочитаю разыскивать имена идентификаторов, которые соответствуют имени id в стартовом ключе. Таким образом, вы всегда знаете, что клиент будет присоединяться к customerid в любой другой таблице, в которой есть столбец.

Никогда не используйте имя в качестве имени поля. Это зарезервированное слово, и его следует избегать. Зарезервированные keyworsds используются базой данных в некотором роде, используя их также, поскольку зарегистрированные имена - это просто плохая проакция и могут создавать больше ошибок, чем использование правильного описательного имени в начале.

Answer 9

Проверить вопрос также связан: Is prefixing each field name in a table with abbreviated table name a good practice?

Как I mentioned in my answer; концепция префикса имен полей с именем таблицы происходит из старого времени устаревших систем, когда каждое поле всей базы данных должно быть уникальным. Это больше не требуется современными системами, поэтому это просто соглашение, которое больше не требуется. Как отметил Think Before Coding «Имя таблицы уже дает контекст. Нет необходимости префиксов столбцов не имя с ним»

Answer 10

Я думаю, что если имя столбца не является уникальным в базе данных, вы должны префикс с именем таблицы. Например, ProductId, ProductName. Для столбцов, не противоречащих столбцам в другой таблице, не префикс.

Answer 11

Вариант 2 - лучший (для меня конечно :)),
Я программист PHP, а не .NET.

Answer 12

Я предпочитаю второй вариант, потому что первый вариант, для меня, кажется, лишним повторением. Конечно, я в первую очередь программист Ruby on Rails, поэтому мне нравится DRY principle. :) Я нахожу это раздражающим приходом к программированию на C#, потому что все использует первую, явную, но повторяющуюся версию.