Конвенції про іменування баз даних, таблиці та стовпців? [зачинено]

Щоразу, коли я проектую базу даних, я завжди замислююся про те, чи є найкращий спосіб іменування елемента в моїй базі даних. Досить часто я задаю собі такі питання:

1. Чи повинні назви таблиць бути множинними?
2. Чи повинні назви стовпців бути однинами?
3. Чи слід префіксувати таблиці чи стовпці?
4. Чи слід використовувати будь-який випадок при називанні предметів?

Чи є якісь рекомендовані вказівки щодо іменування елементів у базі даних?

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

У зразку AdventureWorks використовується дуже чітка і послідовна конвенція іменування, яка використовує назви схем для організації об'єктів бази даних.

1. Окремі назви таблиць
2. Сингулярні назви стовпців
3. Назва схеми для префіксу таблиць (наприклад: SchemeName.TableName)
4. Корпус Паскаля (він же верхній корпус верблюда)

Тут пізня відповідь, але коротко:

1. Мої переваги - множина
2. Так
3. Таблиці : * Зазвичай * найкращі жодні префікси. Стовпці : Ні.
4. Обидві таблиці та стовпці: PascalCase.

Розробка:

(1) Що ви повинні зробити. Є дуже мало речей, які ви повинні робити певним чином кожен раз, але є кілька.

• Назвіть свої первинні ключі, використовуючи формат "[singularOfTableName]". Тобто, чи є ім’я вашої таблиці Клієнт чи Клієнти , первинним ключем має бути CustomerID .
• Крім того, іноземні ключі повинні послідовно називатися в різних таблицях. Потрібно законно бити того, хто цього не робить. Я зазначу, що хоча визначені обмеження зовнішніх ключів часто важливі, послідовне іменування іноземних ключів завжди важливе
• У вашій базі даних повинні бути внутрішні умови . Незважаючи на те, що в наступних розділах ви бачите, що я дуже гнучка, імена в базі даних повинні бути дуже послідовними. Незалежно від того, чи називається ваш стіл для клієнтів « Клієнти» або « Клієнт» , менш важливо, ніж ви робите це так само в одній і тій же базі даних. Ви можете перевернути монету, щоб визначити, як користуватися підкресленнями, але тоді вам слід продовжувати використовувати їх так само . Якщо ви цього не робите, ви погана людина, яка повинна мати низьку самооцінку.

(2) Що ви, ймовірно, повинні зробити.

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

(3) Що слід врахувати.

• Я дійсно думаю, що у вас повинні бути множинні назви для таблиць; деякі вважають одниною. Прочитайте аргументи в іншому місці. Назви стовпців мають бути одиничними. Навіть якщо ви використовуєте множинні назви таблиць, таблиці, які представляють комбінації інших таблиць, можуть бути в однині. Наприклад, якщо у вас є таблиця " Акції" та " Елементи", таблиця, що представляє предмет, який є частиною рекламної кампанії, може бути Promotions_Items, але він також може законно бути Promotion_Items, я думаю (відображає взаємозв'язок "один до багатьох").
• Використовуйте підкреслення послідовно та з певною метою. Просто імена загальних таблиць повинні бути досить чіткими з PascalCasing; вам не потрібні підкреслення для розділення слів. Збережіть підкреслення або (a), щоб вказати асоціативну таблицю, або (b) для префіксації, про яку я звертатимусь у наступній букві.
• Префіксація не є ні доброю, ні поганою. Це , як правило , не краще. У вашому першому дБ або двох я не пропоную використовувати префікси для загального тематичного групування таблиць. Таблиці зрештою не відповідають вашим категоріям, і це може ускладнити пошук таблиць. Маючи досвід, ви можете спланувати та застосувати схему префіксів, яка приносить більше користі, ніж шкоди. Я працював колись у db, де таблиці даних починалися з tbl , таблиці config з ctbl , перегляди з vew , proc's sp та udf's fn, та кілька інших; це було прискіпливо, послідовно застосовувалося, так що все вийшло нормально. Єдиний раз, коли ви потребуєте префіксів, це коли у вас є справді окремі рішення, які чомусь перебувають у тому ж db; префіксація їх може бути дуже корисною при групуванні таблиць. Префіксація також нормальна для спеціальних ситуацій, як-от для тимчасових таблиць, які ви хочете виділити.
• Дуже рідко (якщо ніколи) ви хочете встановити префікс стовпців.

Гаразд, оскільки ми зважуємо думку:

Я вважаю, що назви таблиць мають бути множинами. Таблиці - це сукупність (таблиця) сутностей. Кожен рядок являє собою єдине ціле, а таблиця представляє колекцію. Тож я б назвав таблицю осіб, що складаються з людей (або Особи, що б то не захопило).

Для тих, хто любить бачити поодинокі "імена сутностей" у запитах, саме це я б використовував псевдоніми таблиць для:

SELECT person.Name
FROM People person

Трохи як LINQ "від людини в людей вибирають person.Name".

Що стосується 2, 3 і 4, я згоден з @Lars.

Я працюю в команді підтримки бази даних з трьома DBA, і розглядаються наші варіанти:

1. Будь-який стандарт іменування кращий, ніж жоден стандарт.
2. Немає "жодного справжнього" стандарту, у всіх нас є свої уподобання
3. Якщо вже існує стандарт, використовуйте його. Не створюйте інший стандарт чи не мутний існуючі стандарти.

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

Для полів ми очікуємо, що імена полів включатимуть префікс / акріонм таблиці (тобто cust_address1), а також ми віддаємо перевагу використанню стандартного набору суфіксів (_id для PK, _cd для "коду", _nm для "name ", _nb для" числа ", _dt для" Дата ").

Ім'я поля ключа Foriegn має бути таким же, як і поле первинного ключа.

тобто

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

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

1. Ні. Таблиця повинна бути названа за суттю, яку вона представляє. Особа, а не людина - це те, як ви ставитесь до того, хто представляє один із записів.
2. Знову те саме. Стовпчик FirstName дійсно не повинен називатися FirstNames. Все залежить від того, що ви хочете представляти зі стовпцем.
3. НІ.
4. Так. Вважайте це за ясність. Якщо вам потрібно мати стовпчики типу "FirstName", корпус полегшить читання.

Добре. Це мої $ 0,02

Я також виступаю за конвенцію іменування стилів ISO / IEC 11179, зазначивши, що вони є настановами, а не рецептурними.

Дивіться назву елемента даних у Вікіпедії :

"Таблиці - це колекції сутностей і дотримуйтесь інструкцій щодо іменування колекції. В ідеалі використовується колективне ім'я: напр., Персонал. Множина також є правильним: співробітники. Невірні назви включають: Співробітник, tblE Employee та EmployeeTTable."

Як завжди, є винятки з правил, наприклад, таблиця, яка завжди має рівно один рядок, може бути кращою з назвою однини, наприклад, таблиця конфігурацій. І послідовність має надзвичайно важливе значення: перевірити, чи є у вас магазин, чи є такий конвент, і, якщо так, дотримуйтесь його; якщо вам це не подобається, то зробіть діловий випадок, щоб він змінився, а не був самотнім рейнджером.

Я весь час чую аргументи, що чи множина таблиця множина - це питання особистого смаку, і немає найкращої практики. Я не вірю, що це правда, особливо як програміст на відміну від DBA. Наскільки мені відомо, немає законних причин множитися назвою таблиці, окрім "Це для мене просто має сенс, тому що це колекція об'єктів", в той час як є законні вигоди в коді, маючи особливі назви таблиць. Наприклад:

1. Це дозволяє уникнути помилок і помилок, викликаних множинними двозначностями. Програмісти точно не відомі своєю орфографічною експертизою, а множина деяких слів викликає заплутаність. Наприклад, чи закінчується слово множини на "es" або просто "s"? Це люди чи люди? Коли ви працюєте над проектом з великими командами, це може стати проблемою. Наприклад, екземпляр, коли член команди використовує неправильний метод для плюралізації створеної ним таблиці. На той час, коли я взаємодію з цією таблицею, вона використовується повсюдно в коді, до якого я не маю доступу або потребуватиме занадто багато часу, щоб виправити. У результаті я маю пам’ятати, що правопис таблиці неправильно пишеться кожного разу, коли я її використовую. Зі мною трапилось щось дуже схоже на це. Чим простіше ви можете зробити це для кожного члена команди послідовно і легко використовувати точне, виправляти назви таблиць без помилок або постійно шукати назви таблиць, тим краще. Сингулярну версію набагато простіше обробляти в командному середовищі.

2. Якщо ви використовуєте сингулярну версію імені таблиці І префікс первинного ключа з назвою таблиці, то тепер ви маєте перевагу в тому, щоб легко визначити ім'я таблиці за допомогою первинного ключа або навпаки, лише за допомогою коду. Ви можете надати змінну з назвою таблиці в ній, об'єднати "Id" до кінця, і тепер у вас є первинний ключ таблиці за допомогою коду, не потребуючи додаткового запиту. Або ви можете відрізати "Id" від кінця первинного ключа, щоб визначити ім'я таблиці за допомогою коду. Якщо ви використовуєте "id" без назви таблиці для первинного ключа, ви не можете за допомогою коду визначити ім'я таблиці з первинного ключа. Крім того, більшість людей, які множують назви таблиць та префікси стовпців ПК із назвою таблиці, використовують єдину версію імені таблиці в ПК (наприклад, статуси та статус_id),

3. Якщо ви зробите назви таблиць сингулярними, то вони можуть відповідати назвам класів, які вони представляють. Знову ж таки, це може спростити код і дозволити вам робити дійсно акуратні речі, наприклад інстанціювання класу, не маючи нічого, крім назви таблиці. Це також просто робить ваш код більш послідовним, що призводить до ...

4. Якщо ви зробите ім’я таблиці єдиним, це зробить вашу схему імен послідовною, організованою та простою в обслуговуванні у кожному місці. Ви знаєте, що в кожному екземплярі вашого коду, будь то в назві стовпця, в якості імені класу чи як імені таблиці, це те саме ім’я. Це дозволяє вам робити глобальний пошук, щоб побачити всюди, де використовуються дані. Під час плюралізації імені таблиці будуть випадки, коли ви будете використовувати сингулярну версію цього імені таблиці (клас, в який вона перетворюється, в первинному ключі). Просто має сенс не мати деяких випадків, коли ваші дані називаються множиною, а деякі випадки однини.

Підсумовуючи це, якщо ви множимо назви своїх таблиць, ви втрачаєте всілякі переваги в тому, щоб зробити свій код розумнішим та простішим в обробці. Можливо, навіть існують випадки, коли вам потрібно мати таблиці / масиви пошуку, щоб перетворити назви ваших таблиць у об'єктні або локальні кодові імена, яких ви могли уникнути. Назви одинарних таблиць, хоча, мабуть, спочатку виглядають трохи дивно, але пропонують значні переваги перед множинними іменами, і я вважаю, що це найкраща практика.

наші переваги:

1. Чи повинні назви таблиць бути множинними?
   Ніколи. Аргументи того, що це колекція, мають сенс, але ви ніколи не знаєте, що міститиме таблиця (0,1 або багато елементів). Правила множини роблять іменування зайвим складним. 1 будинок, 2 будинки, миші проти мишей, людина проти людей, і ми навіть не переглядали жодної мови.

   Update person set property = 'value'діє на кожну людину в таблиці.
   Select * from person where person.name = 'Greg'повертає колекцію / набір рядків осіб.

2. Чи повинні назви стовпців бути однинами?
   Зазвичай, так, за винятком випадків, коли ви порушуєте норми нормалізації.

3. Чи слід префіксувати таблиці чи стовпці?
   Переважно перевагу платформи. Ми вважаємо за краще префікс стовпців із назвою таблиці. Ми не префіксуємо таблиці, але робимо представлення префіксів (v_) та зберігаються_процедури (sp_ або f_ (функція)). Це допомагає людям, які хочуть спробувати оновити v_person.age, що насправді є обчисленим полем у представленні (яке ніяк не можна оновити).

   Це також чудовий спосіб уникнути зіткнення ключових слів (доставка.від перерв, але доставка_від цього не робить).

   Це робить код більш багатослівним, але часто допомагає читати.

   bob = new person()
bob.person_name = 'Bob'
bob.person_dob = '1958-12-21'
   ... дуже читабельний і явний. Це може вийти з рук, хоча:

   customer.customer_customer_type_id

   вказує на взаємозв'язок між клієнтом та таблицею типу клієнта, вказує на первинний ключ у таблиці типу_замовника (customer_type_id), і якщо ви коли-небудь побачите 'customer_customer_type_id' під час налагодження запиту, ви моментально знаєте, звідки він (таблиця клієнта).

   або там, де у вас є взаємозв'язок між ММ між клієнтом і категорією споживача (для певних категорій доступні лише певні типи)

   customer_category_customer_type_id

   ... трохи (!) на довгій стороні.

4. Чи слід використовувати будь-який випадок при називанні предметів? Так - нижній регістр :), з підкресленнями. Це дуже зручні для читання платформи. Разом з 3 вище це також має сенс.

   Більшість із них є вподобаннями. - Поки ви послідовні, це має бути передбачуваним для кожного, хто має його читати.

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

Я про це блогував деякий час назад: ISO-11179 Іменування конвенцій

Я знаю, що це вже пізно до гри, і на питання вже відповіли дуже добре, але я хочу запропонувати свою думку щодо №3 щодо префіксації назв стовпців.

Усі стовпці мають бути названі префіксом, який є унікальним для таблиці, у якій вони визначені.

Наприклад, враховуючи таблиці "замовник" та "адреса", давайте переходимо з префіксами "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%';

Мої думки з цього приводу:

1) Ні, назви таблиць мають бути єдиними.

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

Таблиця в БД - це дійсно сукупність цієї сутності, вона має більше сенсу, коли ви використовуєте set-logic:

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

Цей останній рядок, власне логіка з'єднання, виглядає заплутаним у множині імен таблиць.

Я не впевнений, що завжди використовувати псевдонім (як пропонує Метт) це очищає.

2) Вони повинні бути поодинокими, оскільки вони мають лише 1 майно

3) Ніколи, якщо назва стовпця неоднозначне (як вище, де в обох є стовпець під назвою [Ключ]), ім’я таблиці (або його псевдоніму) не може їх досить добре розрізнити. Ви хочете, щоб запити були швидкими, а прості - префікси додають зайву складність.

4) Що б ви не хотіли, я пропоную CapitalCase

Я не думаю, що існує один набір абсолютних настанов щодо будь-якого з них.

Поки все, що ви вибираєте, є узгодженим у додатку чи БД, я не думаю, що це насправді має значення.

На мою думку:

1. Назви таблиць мають бути множинами.
2. Назви стовпців мають бути єдиними.
3. Ні.
4. Або CamelCase (мій вподобаний), або підкреслити_seserated як для назв таблиць, так і для імен стовпців.

Однак, як уже згадувалося, будь-яка конвенція є кращою, ніж жодна конвенція. Незалежно від того, як ви вирішите це зробити, документуйте це так, щоб майбутні модифікації відповідали тим же умовам.

Я думаю, що найкращу відповідь на кожне з цих питань ви б дали вам та вашій команді. Набагато важливіше скласти конвенцію про іменування, а потім, наскільки саме вона називається.

Оскільки на це немає правильної відповіді, вам слід зайняти деякий час (але не надто багато) і вибрати власні конвенції і - ось важлива частина - дотримуйтесь цього.

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

На всякий випадок, ось мої відповіді:

1. Так. Таблиця - це група записів , викладачів чи акторів , тому ... множина.
2. Так.
3. Я не користуюся ними.
4. База даних, яку я частіше використовую - Firebird - зберігає все у верхньому регістрі, тому це не має значення. У будь-якому разі, коли я програмую, я пишу імена таким чином, щоб їх було легше читати, як, наприклад, реліз року .

1. Однозначно зберігайте назви таблиць однини, людина не люди
   2. Те ж саме
   3. Ні. Я бачив деякі жахливі префікси, аж до того, щоб заявити про те, з чим мали справу, - це таблиця (tbl_) або процедура зберігання користувача (usp_). Після цього слід назвати базу даних ... Не робіть цього!
   4. Так. Я схильний PascalCase всі свої назви таблиць

Конвенції про іменування дозволяють команді розробників розробити можливість виявлення та ремонту в основі проекту.

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

Ось мої відповіді:

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

Ім'я важко, але в кожній організації є хтось, хто може назвати речі, і в кожній команді програмного забезпечення повинен бути хтось, хто бере на себе відповідальність за стандарти імен і гарантує, що проблеми іменування, такі як sec_id , sec_value та security_id, будуть вирішені достроково, перш ніж їх отримати в проекті .

Отож, які основні положення хорошої конвенції про іменування та стандарти:

• Використовуйте мову свого клієнта та домен рішення
• Будьте описовими
• Будьте послідовними
• Розділіть, віддзеркалюйте та рефактор
• Не використовуйте скорочення, якщо вони не зрозумілі всім
• Не використовуйте зарезервовані ключові слова SQL як імена стовпців

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

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

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

Назви таблиць завжди мають бути поодинокими, оскільки вони представляють набір об’єктів. Як ви кажете, стадо позначає групу овець, або отара позначає групу птахів. Не потрібно множини. Коли назва таблиці складається з двох імен, а умовна назва - множиною, важко дізнатися, чи має ім'я множини перше слово чи друге слово чи обидва. Це логіка - Object.instance, а не object.instance. Або TableName.column, а не TableNames.column (s). Microsoft SQL не відрізняється від регістру, і легше читати назви таблиць, якщо використовуються великі літери, щоб відокремити назви таблиць або стовпців, коли вони складаються з двох і більше імен.

Назва таблиці: Вона повинна бути поодинокою, оскільки це єдине ціле, що представляє об'єкт реального світу, а не об'єкти, яке є єдиним.

Назва стовпця: Він повинен бути єдиним, тільки тоді він повідомляє, що він буде мати атомне значення і підтвердить теорію нормалізації. Якщо ж є n кількість однотипних властивостей, то їх слід суфіксувати з 1, 2, ..., n тощо.

Префіксація таблиць / стовпців: це величезна тема, обговоримо пізніше.

Корпус: Це повинен бути корпус верблюда

Мій друг, Патрік Карчер , я прошу вас не писати нічого, що може когось образити, як ви писали: "• Далі, іноземні ключі повинні називатися послідовно в різних таблицях. Потрібно законно бити того, хто цього не робить зробити це.". Я ніколи не робив цієї помилки мій друг Патрік, але пишу взагалі. Що робити, якщо вони разом планують побити вас за це? :)

Дуже пізно на вечірку, але я все ж хотів додати свої два центи про префікси стовпців

Здається, є два основні аргументи для використання стандарту іменування table_column (або tableColumn) для стовпців, обидва виходячи з того, що сама назва стовпця буде унікальною для всієї вашої бази даних:

1) Вам не потрібно постійно вказувати назви таблиць та / або псевдоніми стовпців у ваших запитах

2) Ви можете легко шукати весь код за назвою стовпця

Я думаю, що обидва аргументи є помилковими. Рішення обох проблем без використання префіксів є простим. Ось моя пропозиція:

Завжди використовуйте ім'я таблиці у своєму SQL. Наприклад, завжди використовуйте table.column замість стовпця.

Очевидно, це вирішує 2), оскільки тепер ви можете просто шукати table.column замість table_column.

Але я чую, як ти кричиш, як це вирішує 1)? Йшлося саме про те, щоб уникнути цього. Так, це було, але рішення було жахливо хибним. Чому? Ну, рішення префікса зводиться до:
Щоб уникнути необхідності вказувати table.column, коли є неоднозначність, ви називаєте всі свої стовпці table_column!
Але це означає, що відтепер вам доведеться писати ім'я стовпця щоразу, коли ви вказуєте стовпець. Але якщо вам це доведеться робити все-таки, яка користь від того, щоб завжди явно писати table.column? Точно ніякої користі немає, це саме таку кількість символів для введення.

редагувати: так, я знаю, що іменування стовпців з префіксом вимагає правильного використання, тоді як мій підхід покладається на програмістів

Основні бази даних про іменування конвенцій (та стилю) (натисніть тут для більш детального опису)

назви таблиць вибирають короткі, однозначні імена, використовуючи не більше одного або двох слів, розрізняють таблиці, легко полегшує називання унікальних імен полів, а також пошук і зв'язування таблиць дають таблиці сингулярні імена, ніколи не множинні (оновлення: я все ще згоден з наведеними причинами для цієї конвенції, але більшості людей дуже подобаються множинні назви таблиць, тому я пом’якшив свою позицію) ... перейдіть за посиланням вище, будь ласка

Назви таблиць однини. Скажімо, ви моделювали зв'язок між кимось та їх адресою. Наприклад, якщо ви читаєте модуль даних, ви хочете, щоб "кожна людина може жити за 0,1 або багатьма адресами". або "кожен народ може жити за 0,1 або багатьма адресами". Я думаю, що простіше множитися адресою, ніж перефразовувати людей як людину. Плюс збірних іменників досить часто відмінні від однини.

--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. Випадок Pascal для імен таблиць і стовпців, префікса + ВСІ обмежувальні знаки для індексів та обмежень.