Якого стандарту слід дотримуватися, називаючи таблиці та представлення?

Якого стандарту слід дотримуватися, називаючи таблиці та представлення? Наприклад, чи є гарною ідеєю ставити щось на зразок tbl_ на початку назв таблиці? Чи повинен я призначити таблиці коду / пошуку таким чином, як ct_, lut_ або code_? Чи є ще якісь робити чи не робити?

Я використовую MS SQL Server і маю багато баз даних з багатьма таблицями, тому було б непогано мати щось, що ми можемо використовувати в якості стандарту з деякими підтримуючими раціональними.

Гаразд, спочатку НІКОЛИ не ставте tbl перед назвою таблиці. Це стіл, ми вже зараз це. Це називається угорська нотація, і люди припинили це робити ще 5 років тому.

Просто викличте об'єкт, грунтуючись на тому, що він є. Якщо в таблиці зберігаються дані працівника, називайте її «Співробітником». Якщо він містить інформацію про комп'ютери, називайте його "Комп'ютер". Якщо він відображає комп’ютери для співробітників, вони називають його "EmployeeComputer" або "ComputerE Employee" (особисто мені більше подобається "EmployeeComputer").

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

Ми використовуємо схеми (можливо, думайте про них як простори імен у SQL) як для дозволів, так і для групування. Тож замість "tbl" тощо ми маємо

• Data.Thing
• Data.ThingHistory
• Data.Stuff

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

Для представлень, які ми використовуємо, vwале це було для того, щоб відрізнити їх від таблиць у SQL Server 2000, і це свого роду спадщина зараз

Особисто я великий шанувальник Fanö Bedingung , маючи на увазі, що це ім'я не може бути початком іншого дійсного імені.

А по-друге, відстань Хеммінга між двома іменами краще, ніж одна різна літера.

Так, це правило з добітальних часів, але вони полегшують життя.

І треті імена повинні бути вимовними, інакше ви з’їдете з розуму, коли розпізнавання голосу стане правдою.

Я не знаю, що там дійсно існує якась «найкраща» конвенція про іменування, оскільки вона дійсно зводиться до особистих уподобань та простоти розвитку. Моя порада - вибрати конвенцію про іменування та дотримуватися її. Якщо ви хочете відокремити слова з підкресленням, зробіть це у всіх об'єктах бази даних. Якщо ви хочете використовувати camelCase, зробіть це у всіх об'єктах бази даних.

У моєму магазині ми дотримуємось наступних правил:

Ми розділяємо слова з підкресленнями і використовуємо всі маленькі літери.
Назви наших таблиць описують, що вони: dbo.person, dbo.invoice.
Наші імена таблиць з багатьма множинами також описують, що вони є (з додаванням мм для позначення відображення співвідношення багато-багато: dbo.person_mm_address. Наші визначені користувачем збережені процедури описують як об'єкт, так і дію, що виконується: usp_person_select , usp_address_select_by_city Наші погляди та функції відповідають тим же правилам, що і збережені процедури. Наші покажчики включають таблицю, ключові стовпці (по порядку) та вказівку на кластеризовану / некластеризовану: ix_person_last_name_first_name_nc

Тільки тому, що це те, що ми використовуємо в моєму магазині, це не означає, що ці правила підходять саме вам. Виберіть щось, з чим ви згодні з вашою командою розробників, і корисно, і легко розробити, і встановіть культуру знання та використання будь-якої конвенції про іменування, яку ви вирішите. У нашому випадку це включає перегляд коду для будь-яких об’єктів, створених у базі даних. З часом поєднання задокументованої конвенції про іменування та перегляд коду однорангових кодів призвело до меншої та меншої кількості відхилень від умовності.

Я сподіваюся, що ця "невідповідь" певним чином допомагає.

Я задоволений цим з років тому

• назви таблиць: маленькі кришки та підкреслення, однина {замовник, товар}
• назви таблиць для багатьох до багатьох відносин: tablename1_tablename2: {customer_product}
• перегляди: маленькі кришки додано v до кінця {customerv, productv, product_groupv}
• збережені пристрої: ім'я та функції таблиці {customer_select, customer_insert, customer_delete, customer_update}

якщо у вас є дешевий спільний хостинг-пакет, вам потрібно буде використовувати абревіатуру проекту перед усіма вашими об'єктами, як-от, наприклад, веб-сайт адміністраторів баз даних, da_users, da_questions