Именование решений для таблиц базы данных [duplicate]

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

Шаг 0: git log

Посмотрите, где вы находитесь git log. Самое главное, найдите хеш фиксации первой фиксации, которую вы не хотите , чтобы сквош. Таким образом, только:

Шаг 1: git rebase

Выполнить git rebase -i [your hash] , в мой случай:

$ git rebase -i 2d23ea524936e612fae1ac63c95b705db44d937d

Шаг 2: выберите / сквош, что вы хотите

В моем случае я хочу раздавить все на коммит, который был первым во времени. Порядок от первого до последнего, так точно так же, как в git log. В моем случае я хочу:

Шаг 3: Отрегулировать сообщения (ы)

Если вы выбрали только одно коммит и раздавили остальное, вы можете настроить одно сообщение фиксации:

Вот и все. Как только вы сохраните это (:wq), все готово. Посмотрите на это с помощью git log.

638
задан DOK 29 September 2011 в 15:40
поделиться

23 ответа

Я рекомендую проверить образцы баз данных Microsoft SQL Server: https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

The AdventureWorks sample использует очень четкое и последовательное соглашение об именах, которое использует имена схем для организации объектов базы данных.

  1. Сингулярные имена для таблиц
  2. Сингулярные имена для столбцов
  3. Имя схемы для префикса таблиц (например: SchemeName.TableName)
  4. Паскаль (например, верхний верблюд)
249
ответ дан Cas Bloem 4 September 2018 в 08:06
поделиться

Названия таблиц всегда должны быть сингулярными, поскольку они представляют собой набор объектов. Как вы говорите, стадо назначать группу овец, или стадо обозначают группу птиц. Нет необходимости во множественном числе. Когда имя таблицы представляет собой состав из двух имен, а соглашение об именах во множественном числе, становится трудно узнать, должно ли имя множественного числа быть первым словом или вторым словом или и тем, и другим. Это логика - Object.instance, а не object.instance. Или TableName.column, а не TableNames.column (s). Microsoft SQL не чувствителен к регистру, легче читать имена таблиц, если используются буквы верхнего регистра, для разделения имен таблиц или столбцов, когда они состоят из двух или более имен.

5
ответ дан Annie 4 September 2018 в 08:06
поделиться

Основные обозначения именования баз данных (и стиль) (нажмите здесь для более подробного описания).

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

3
ответ дан AZ_ 4 September 2018 в 08:06
поделиться

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

http://justinsomnia.org/writings/naming_conventions.html

8
ответ дан Chris 4 September 2018 в 08:06
поделиться

Я постоянно слышу, что аргумент о том, что плюрализуется таблица, - это все, что касается личного вкуса, и нет лучшей практики. Я не верю, что это правда, особенно как программист, а не DBA. Насколько мне известно, нет никаких законных оснований для плюрализации имени таблицы, отличного от «Это просто имеет смысл для меня, потому что это коллекция объектов», хотя есть законные выигрыши в коде с помощью уникальных имен таблиц. Например:

  1. Это позволяет избежать ошибок и ошибок, вызванных множественными двусмысленностями. Программисты точно не известны своими знаниями о правописании, а плюризация некоторых слов сбивает с толку. Например, слово множественного числа заканчивается на «es» или просто «s»? Это люди или люди? Когда вы работаете над проектом с большими командами, это может стать проблемой. Например, экземпляр, в котором член команды использует неправильный метод для размножения созданной таблицы. К тому времени, когда я взаимодействую с этой таблицей, она используется повсюду в коде, к которому у меня нет доступа или потребуется долго исправлять. В результате я должен помнить, что каждый раз, когда я его использую, неправильно повторяю таблицу. Что-то очень похожее на это произошло со мной. Чем проще вы можете сделать это для каждого члена команды, чтобы последовательно и легко использовать точные, правильные имена таблиц без ошибок или постоянно искать имена таблиц, тем лучше. Единственная версия гораздо проще обрабатывать в командной среде.
  2. Если вы используете единственную версию имени таблицы И префикс первичного ключа с именем таблицы, теперь у вас есть преимущество в том, что вы легко можете определить таблицу имя из первичного ключа или наоборот с помощью кода. Вы можете получить переменную с именем таблицы в ней, объединить «Id» до конца, и теперь у вас есть первичный ключ таблицы через код, без необходимости делать дополнительный запрос. Или вы можете отключить «Id» с конца первичного ключа, чтобы определить имя таблицы через код. Если вы используете «id» без имени таблицы для первичного ключа, вы не можете через код определить имя таблицы из первичного ключа. Кроме того, большинство людей, которые используют множественные имена таблиц и префиксные столбцы PK с именем таблицы, используют сингулярную версию имени таблицы в PK (например, статусы и statusId), что делает невозможным это вообще.
  3. Если вы делаете имена таблиц сингулярными, их можно сопоставить именам классов, которые они представляют. Еще раз, это может упростить код и позволить вам делать действительно аккуратные вещи, такие как создание экземпляра класса, имея только имя таблицы. Это также просто делает ваш код более последовательным, что приводит к ...
  4. Если вы сделаете имя таблицы уникальным, это сделает вашу схему именования согласованной, организованной и простой в обслуживании в каждом месте. Вы знаете, что в каждом экземпляре вашего кода, будь то имя столбца, имя класса или имя таблицы, это то же точное имя. Это позволяет выполнять глобальные поиски, чтобы везде видеть, что данные используются. Когда вы дублируете имя таблицы, будут случаи, когда вы будете использовать сингулярную версию имени этой таблицы (класс, в который он входит, в первичном ключе). Просто имеет смысл не иметь некоторых случаев, когда ваши данные упоминаются как множественное число, а некоторые экземпляры сингулярны.

Подводя итог, если вы дублируете свои имена таблиц, вы теряете все виды преимущества в том, чтобы сделать ваш код умнее и проще в обращении. Могут даже быть случаи, когда вы должны иметь таблицы поиска / массивы для преобразования имен таблиц в имена объектов или локальных кодов, которых вы могли бы избежать. Сингулярные имена таблиц, хотя, возможно, сначала немного странные, дают существенные преимущества перед плюрализованными именами, и я считаю, что это лучшая практика.

17
ответ дан dallin 4 September 2018 в 08:06
поделиться
  1. Нет. Таблица должна быть названа в честь объекта, который она представляет. Человек, а не человек, как вы относитесь к тому, кто представляет из себя одну из записей.
  2. Опять же, то же самое. Столбец FirstName действительно не следует называть FirstNames. Все зависит от того, что вы хотите представить в столбце.
  3. NO.
  4. Да. Делайте это для ясности. Если вам нужны столбцы, такие как «FirstName», корпус упростит чтение.

Хорошо. Thats мои $ 0,02

43
ответ дан DanMan 4 September 2018 в 08:06
поделиться
  1. Определенно, чтобы имена таблиц были единичными, люди не люди. Здесь же. Нет. Я видел некоторые ужасные префиксы, договариваясь о том, что имеет дело с таблицей (tbl_) или процедурой хранения пользователей (usp_ ). Затем следует имя базы данных ... Не делайте этого! Да. Я склонен к PascalCase всем моим именам таблиц
11
ответ дан ErikE 4 September 2018 в 08:06
поделиться

Я знаю, что это уже поздно, и на этот вопрос уже был дан очень хорошо, но я хочу предложить свое мнение о №3 относительно префикса имен столбцов.

Все столбцы должны быть named с префиксом, который уникален для таблицы, в которой они определены.

Например Учитывая таблицы «клиент» и «адрес», давайте перейдем с префиксами «cust» и «addr» соответственно. «клиент» имел бы «cust_id», «cust_name» и т. д. в нем. «address» будет иметь «addr_id», «addr_cust_id» (FK обратно к клиенту), «addr_street» и т. д.

Когда мне впервые был представлен этот стандарт, я был мертв против Это; Я ненавидел эту идею. Я не мог выдержать идею о том, что это лишний набор и избыточность. Теперь у меня было достаточно опыта, чтобы я никогда не возвращался.

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

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

Преимущество №1 невероятно велико. Я могу обесценить столбец и точно знать, какие файлы необходимо обновить до того, как столбец можно безопасно удалить из схемы. Я могу изменить значение столбца и точно знать, какой код нужно реорганизовать. Или я просто могу сказать, используются ли данные из столбца в определенной части системы. Я не могу сосчитать количество раз, когда это превратило потенциально огромный проект в простой, а также количество часов, которые мы сохранили в процессе разработки.

Еще одна, относительно небольшая польза от этого - это то, что вам нужно использовать табличные псевдонимы, когда вы делаете самостоятельное соединение:

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';
14
ответ дан Granger 4 September 2018 в 08:06
поделиться

Я работаю в команде поддержки базы данных с тремя администраторами баз данных, и наши рассмотренные варианты:

  1. Любой стандарт именования лучше, чем стандартный.
  2. Нет ни одного истинный "стандарт, у всех нас есть наши предпочтения
  3. Если стандарт уже установлен, используйте его. Не создавайте другой стандарт или мутные существующие стандарты.

Мы используем уникальные имена для таблиц. Таблицы имеют префикс с именем системы (или ее сокращением). Это полезно, если системный комплекс, поскольку вы можете изменить префикс для логической группировки таблиц (например, reg_customer, reg_booking и regadmin_limits).

Для полей мы ожидаем, что имена полей будут включать префикс / acryonm таблицы (т.е. cust_address1), и мы также предпочитаем использовать стандартный набор суффиксов (_id для PK, _cd для «code», _nm для «name», _nb для «number», _dt для «Date») .

Имя поля ключа Foriegn должно совпадать с полем основного поля.

т.е.

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

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

67
ответ дан Guy 4 September 2018 в 08:06
поделиться
4
ответ дан janb 4 September 2018 в 08:06
поделиться

Хорошо, поскольку мы взвешиваем мнение:

Я считаю, что имена таблиц должны быть множественными. Таблицы представляют собой коллекцию (таблицу) объектов. Каждая строка представляет собой единый объект, а таблица представляет коллекцию. Таким образом, я бы назвал таблицу лиц Людей Людей (или Лиц, независимо от того, что берет ваше воображение).

Для тех, кто любит видеть «запросы сущностей» в запросах, я бы использовал табличные псевдонимы для:

SELECT person.Name
FROM People person

Немного напоминает LINQ «от человека в людях, который выбирает человека. Имя».

Что касается 2, 3 и 4, я согласен с @Lars.

89
ответ дан John Topley 4 September 2018 в 08:06
поделиться

Мое мнение о них:

1) Нет, имена таблиц должны быть сингулярными.

Хотя кажется, что имеет смысл для простого выбора (select * from Orders), это делает меньше смысла для эквивалента OO (Orders x = new Orders).

Таблица в БД действительно является набором этого объекта, имеет смысл, когда вы используете set-logic:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

Эта последняя строка, фактическая логика соединения, выглядит запутанной с именами множественных таблиц.

Я не уверен, что всегда использую псевдоним (как утверждает Мэтт). / g5]

2) Они должны быть сингулярными, поскольку они содержат только 1 свойство

3) Никогда, если имя столбца неоднозначно (как указано выше, где оба они имеют столбец с именем [Key]), имя таблицы (или ее псевдоним) может отличить их достаточно хорошо.

4) Что бы вы ни хотели, я бы предложил CapitalCase

. Я не думаю, что есть один набор абсолютные рекомендации по любому из них.

Пока все, что вы выбираете, согласовано в приложении или БД, я не думаю, что это действительно имеет значение.

14
ответ дан Keith 4 September 2018 в 08:06
поделиться

--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

Это конвенции, которым меня учили, но вы должны адаптироваться ко всему, что использует ваш шланги.

  1. Плюрализм. Это набор объектов.
  2. Да. Атрибут представляет собой представление сингулярного свойства объекта.
  3. Да, имя префиксной таблицы позволяет легко отслеживать имена всех индексов ограничений и псевдонимов таблиц.
  4. Паскаль Случай для имен таблиц и столбцов , prefix + ALL caps для индексов и ограничений.
-1
ответ дан Lord Future 4 September 2018 в 08:06
поделиться

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

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

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

На всякий случай, вот мои ответы:

  1. Да. Таблица представляет собой группу записей , учителей или участников , поэтому ... множественное число.
  2. Да.
  3. Я их не использую.
  4. Базы данных, которые я использую чаще - Firebird - хранит все в верхнем регистре, поэтому это не имеет значения. Во всяком случае, когда я программирую, я пишу имена так, чтобы их было легче читать, например releaseГде .
10
ответ дан Mario Marinato 4 September 2018 в 08:06
поделиться

наше предпочтение:

  1. Должны ли имена таблиц быть множественными? Никогда. Аргументы для него - это коллекция, но вы никогда не знаете, что таблица будет содержать (0,1 или много элементов). Множественные правила делают именование излишне сложным. 1 дом, 2 дома, мышь против мышей, человек против людей, и мы даже не смотрели ни на какие другие языки. Update person set property = 'value' действует на каждого человека в таблице. Select * from person where person.name = 'Greg' возвращает набор строк / строк строк.
  2. Если имена столбцов являются единственными? Обычно, да, кроме случаев, когда вы нарушаете правила нормализации.
  3. Должен ли я префикс таблиц или столбцов? В основном предпочтение от платформы. Мы предпочитаем префикс столбцов с именем таблицы. Мы не префиксные таблицы, но мы делаем префиксные представления (v_) и stored_procedures (sp_ или f_ (function)). Это помогает людям, которые хотят попробовать обновить v_person.age, который на самом деле является вычисленным полем в представлении (которое не может быть UPDATEd в любом случае). Это также отличный способ избежать столкновения с ключевыми словами (доставка. От перерывов, но delivery_from - нет). Это делает код более подробным, но часто помогает в удобочитаемости. bob = new person() bob.person_name = 'Bob' bob.person_dob = '1958-12-21' ... очень читабельна и ясна. Это может выйти из-под контроля: customer.customer_customer_type_id указывает на связь между клиентом и таблицей customer_type, указывает первичный ключ в таблице customer_type (customer_type_id), и если вы когда-либо видите «customer_customer_type_id» при отладке запроса, вы сразу же знаете, где это - из (таблица клиентов). или где у вас есть отношения MM между customer_type и customer_category (только определенные типы доступны для определенных категорий). customer_category_customer_type_id ... немного (!) на длинной стороне.
  4. Должен ли я использовать любой случай в пунктах наименования? Да - нижний регистр :), с подчеркиванием. Это очень читаемая и кросс-платформа. Вместе с 3 выше это также имеет смысл. Однако большинство из них - предпочтения. - Пока вы согласны, это должно быть предсказуемо для всех, кто должен его прочитать.
24
ответ дан Mark 4 September 2018 в 08:06
поделиться
SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName
3
ответ дан matanlurey 4 September 2018 в 08:06
поделиться

Я также поддерживаю соглашение об именах стилей ISO / IEC 11179, отмечая, что они являются рекомендациями, а не предписывающими.

См. Имя элемента данных в Википедии :

«Таблицы представляют собой коллекции сущностей и следуют правилам именования коллекций. В идеале используется коллективное имя: например,« Персонал ». Плюрализм также правильный:« Сотрудники ». Неправильные имена включают в себя: Employee, tblEmployee и EmployeeTable. "

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

31
ответ дан onedaywhen 4 September 2018 в 08:06
поделиться

Названия таблиц единичные. Предположим, вы моделировали реальность между кем-то и их адресом. Например, если вы читаете datamodel, вы бы предпочли «каждый человек может жить на 0,1 или много адресов». или «каждый человек может проживать по 0,1 или много адресов». Я считаю, что его проще адресовать адрес, а не перефразировать людей как личность. Плюс коллективные существительные довольно часто расходятся с сингулярным вариантом.

2
ответ дан paul444 4 September 2018 в 08:06
поделиться

Поздний ответ здесь, но вкратце:

  1. Предпочтение [] [множественное число]
  2. Да
  3. Таблицы : * Обычно * префиксы не лучше. Столбцы : №
  4. Обе таблицы и столбцы: PascalCase.

Разработка:

(1) Что вы должны делать. Есть очень немного вещей, которые вы должны делать делать определенным образом, каждый раз, но есть несколько.

  • Название ваши первичные ключи, используя формат «[singleOfTableName] ID». То есть, будет ли ваше имя таблицы Заказчиком или Клиентами , первичный ключ должен быть CustomerID .
  • Кроме того, иностранные ключи должны последовательно указываться в разных таблицах. Должно быть законно избивать кого-то, кто этого не делает. Я хотел бы представить, что хотя определенные ограничения внешнего ключа часто важны, согласованное именование внешнего ключа всегда важно
  • В базе данных должны быть внутренние соглашения. Хотя в последующих разделах вы увидите, что я очень гибкий, в , имя базы данных должно быть очень последовательным. Клиенты или Customer менее важны для вашей таблицы для клиентов, чем в той же самой базе данных. И вы можете перевернуть монету, чтобы определить, как использовать подчеркивания, но тогда вы должны продолжать использовать их одинаково . Если вы этого не сделаете, вы плохой человек, у которого должна быть низкая самооценка.

(2) Что вы, вероятно, должны сделать.

  • Поля, представляющие один и тот же тип данных в разных таблицах , должны быть названы одинаковыми. Не используйте Zip на одной таблице, а ZipCode - на другом.
  • Чтобы разделить слова в именах таблиц или столбцов, используйте PascalCasing. Использование camelCasing не было бы внутренне проблематичным, но это не соглашение, и это выглядело бы забавно. Я обращу внимание на символы подчеркивания. (Вы не можете использовать ALLCAPS, как в прежние дни. OBNOXIOUSTABLE.ANNOYING_COLUMN был в порядке 20 лет назад, но не сейчас.)
  • Не искусственно сокращать или сокращать слова. Лучше для названия быть длинным и ясным, чем коротким и запутанным. Ультра-короткие имена - это перерыв от более темных, более диких времен. Cus_AddRef. Что это такое? Справочный адрес адресата? Дополнительный возврат клиента?

    • Я действительно думаю, что вы должны иметь множественные имена для таблиц

    (3) ; некоторые думают единственное. Прочитайте аргументы в другом месте. Имена столбцов должны быть единственными. Даже если вы используете множественные имена таблиц, таблицы, представляющие комбинации других таблиц, могут быть в единственном числе. Например, если у вас есть Акции и таблица Items , таблица, представляющая элемент, являющийся частью рекламного объявления, может быть Promotions_Items, но также может быть законно объявлена ​​Promotion_Items I (отражает отношение «один ко многим»).

  • Используйте подчеркивания последовательно и для определенной цели. Просто имена общих таблиц должны быть достаточно ясными с PascalCasing; вам не нужны символы подчеркивания для разделения слов. Сохраните подчеркивания либо (a), чтобы указать ассоциативную таблицу, либо (b) для префикса, которые я буду указывать в следующей брошюре.
  • Префикс не является ни хорошим, ни плохим. Это обычно не лучше. В вашем первом db или двух я бы не предложил использовать префиксы для общей тематической группировки таблиц. Таблицы в конечном итоге не подходят для ваших категорий, и это может сделать труднее найти таблицы. Имея опыт, вы можете планировать и применять схему префикса, которая приносит больше пользы, чем вреда. Я работал в db, когда таблицы данных начинались с tbl , таблицы конфигурации с ctbl , представления с vew , proc sp и udf fn и некоторые другие; это было тщательно, последовательно применялось, так что все получилось хорошо. Единственный раз, когда вам нужны префиксы, - когда у вас действительно есть отдельные решения, которые по какой-то причине находятся в одном и том же дБ; их префиксы могут быть очень полезны при группировке таблиц. Префикс также подходит для особых ситуаций, например, для временных таблиц, которые вы хотите выделить.
  • Очень редко (если когда-либо) вы хотели бы использовать префикс столбцов.
218
ответ дан rogerdpack 4 September 2018 в 08:06
поделиться

Взгляните на ISO 11179-5: Принципы именования и идентификации. Вы можете получить его здесь: http://metadata-standards.org/11179/#11179-5

Я писал об этом некоторое время назад: ISO-11179 Соглашения об именах

19
ответ дан SQLMenace 4 September 2018 в 08:06
поделиться

На мой взгляд:

  1. Названия таблиц должны быть множественными.
  2. Имена столбцов должны быть единственными.
  3. Нет.
  4. Либо CamelCase (мой предпочтительный), либо underscore_separated для имен таблиц и имен столбцов.

Однако, как и было упомянуто, любое соглашение лучше, чем никакое соглашение. Независимо от того, как вы это сделаете, запишите его, чтобы изменения в будущем соответствовали тем же соглашениям.

12
ответ дан Thomas Owens 4 September 2018 в 08:06
поделиться
4
ответ дан vishesh marwah 4 September 2018 в 08:06
поделиться

Соглашения об именах позволяют команде разработчиков разрабатывать открытость и ремонтопригодность в центре проекта.

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

Вот мои ответы:

  1. Да, таблица имена должны быть множественными, если они относятся к набору сделок , ценных бумаг или контрагентов , например.
  2. Да.
  3. Да. Таблицы SQL имеют префикс tb_, представления имеют префикс vw_, хранимые процедуры имеют префикс usp_, а триггеры имеют префикс tg_, за которым следует имя базы данных.
  4. Имя столбца должно быть в нижнем регистре, разделенное знаком подчеркивания.

Именование жестко, но в каждой организации есть кто-то, кто может назвать вещи, и в каждой команде программного обеспечения должен быть кто-то, кто берет на себя ответственность за стандарты прошивки и гарантирует, что проблемы с именованием, такие как sec_id , sec_value и security_id будут решены раньше, чем они будут запечены в проекте.

Итак, каковы основные принципы хорошего именования соглашение и стандарты: -

  • Использовать язык вашего клиента и домен вашего решения
  • Будьте описательным
  • Будьте последовательны
  • Не использовать сокращения, если они не понятны всем
  • Не используйте зарезервированные ключевые слова SQL в качестве имен столбцов
8
ответ дан winsql 4 September 2018 в 08:06
поделиться
Другие вопросы по тегам:

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