Таблиця іменування дилеми: назви однини проти множини [закрито]

Academia стверджує, що назви таблиць мають бути єдиною особою сутності, для якої вони зберігають атрибути.

Мені не подобається будь-який T-SQL, для якого потрібні квадратні дужки навколо імен, але я перейменував Usersтаблицю в єдине, навіки визначаючи тих, хто використовує таблицю, іноді доводиться використовувати дужки.

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

Чи повинен я залишитися чи я повинен йти?

Інші дали досить хороші відповіді, що стосується "стандартів", але я просто хотів додати це ... Чи можливо, що "Користувач" (або "Користувачі") насправді не є повним описом даних, що містяться в таблиці ? Мало того, що вам слід надто з розуму назвати таблиці імена та специфіку, але, можливо, щось подібне "Widget_Users" (де "Віджет" - це назва вашої програми чи веб-сайту) було б більш доречним.

У мене було те саме питання, і прочитавши всі відповіді тут, я обов'язково залишаюся з СІНГУЛЯРНИМ, причинами:

Причина 1 (концепція). Ви можете подумати про мішок, що містить яблука типу "AppleBag", неважливо, чи містить 0, 1 або мільйон яблук, це завжди той самий мішок. Таблиці - це саме те, контейнери, назва таблиці має описувати, що він містить, а не скільки даних він містить. Крім того, поняття множини більше стосується розмовної мови (насправді для визначення наявності одного чи декількох).

Причина 2 . (Зручність). легше вийти з однинами імен, ніж із множинними. Об'єкти можуть мати неправильну множину або взагалі не множину, але завжди матимуть однину (за кількома винятками, як Новини).

• Замовник
• Замовлення
• Користувач
• Статус
• Новини

Причина 3 . (Естетика і порядок). Спеціально для сценаріїв деталізації, це краще читається, краще вирівнюється за назвою та має більш логічний порядок (Основний перший, Детально другий):

• 1.Заказчик
• 2.OrderDetail

У порівнянні з:

• 1.OrderDetails
• 2.Власники

Причина 4 (простота). Складіть всі разом, назви таблиць, основні ключі, відносини, класи уроків ... краще знати лише одне ім’я (однина) замість двох (клас однини, таблиця множини, однина поля, однина-множина множини-деталі .. .)

• Customer
• Customer.CustomerID
• CustomerAddress
• public Class Customer {...}
• SELECT FROM Customer WHERE CustomerID = 100

Коли ви дізнаєтесь, що маєте справу з "Клієнтом", ви можете бути впевнені, що будете використовувати одне і те ж слово для всіх потреб взаємодії з вашою базою даних.

Причина 5 . (Глобалізація). Світ стає все менше, у вас може бути команда різних національностей, не всі володіють англійською мовою як рідною мовою. Неграмовому програмісту з англійської мови було б простіше думати про "сховище", ніж про "сховища" або "статус" замість "статуси". Окремі імена можуть призвести до меншої кількості помилок, спричинених помилками друку, заощадити час, не замислюючись над тим, "чи це дитина чи діти?", А отже, підвищити продуктивність.

Причина 6 . (Чому ні?). Це навіть може заощадити час на письмовій формі, заощадити місце на диску та навіть змусити клавіатуру комп'ютера тривати довше!

• SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
• SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 100

Ви зберегли 3 літери, 3 байти, 3 додаткові хіти клавіатури :)

І нарешті, ви можете назвати тих, хто псується із зарезервованими іменами, як-от:

• Користувач> LoginUser, AppUser, SystemUser, CMSUser, ...

Або використовувати сумнозвісні квадратні дужки [Користувач]

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

Деякі інструменти, такі як LLBLGen, можуть автоматично виправляти імена множини, як "Користувачі до користувача", не змінюючи ім'я таблиці. Чому це має значення? Тому що, коли воно відображається, ви хочете, щоб він виглядав як User.Name замість Users.Name або ще гірше з деяких моїх старих таблиць баз даних, що називають tblUsers.strName, який просто заплутаний у коді.

Моє нове правило - оцінити, як воно буде виглядати, коли воно буде перетворене на об'єкт.

я знайшов одну таблицю, яка не відповідає новому іменуванню, яке я використовую - UsersInRoles. Але завжди буде кілька винятків, і навіть у цьому випадку це добре виглядає як UsersInRoles.Username.

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

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

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

Використання іменника uninflected є простим, логічним, регулярним та незалежним від мови.

Яка умова вимагає, щоб таблиці мали поодинокі назви? Я завжди думав, що це множинні назви.

Користувач додається до таблиці Користувачі.

Цей сайт погоджується:
http://vyaskn.tripod.com/object_naming.htm#Tables

Цей сайт не погоджується (але я не згоден з ним):
http://justinsomnia.org/writings/naming_conventions.html

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

Як щодо цього як простий приклад:

SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"

vs.

SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"

SQL в останньому звучить чужіше, ніж у першому.

Я голосую за однину .

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

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

Я дотримуюся однини для назв таблиць та будь-якої суті програмування.

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

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

Отже, моє правило таке: все є одниною, кожна колекція речей є одниною із доданим s . Допомагає і з ORM.

ІМХО, назви таблиць мають бути множинами, як клієнти .

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

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

Мій головний аргумент полягає в тому, що я не думаю про таблиці як про набір, а як про відносини.

Отже, AppUserспіввідношення говорить про те, які сутності AppUsers.

Співвідношення AppUserGroupпідказує мені, які сутностіAppUserGroups

AppUser_AppUserGroupСтавлення каже мені , як AppUsersі AppUserGroupsпов'язані між собою .

AppUserGroup_AppUserGroupСтавлення каже мені , як AppUserGroupsі AppUserGroupsпов'язані (тобто групи членів групи).

Іншими словами, коли я думаю про сутності та про те, як вони пов’язані між собою, я думаю про відносини в однині, але, звичайно, коли я думаю про сутності в колекціях чи наборах, колекції чи множини є множиною.

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

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

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

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

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

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

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

Прочитавши всі суперечки в цій темі, я дійшов одного висновку:

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

Однини. Я б назвав масив, що містить купу об’єктів представлення рядків користувачів "користувачами", але таблиця - "таблиця користувачів". Думати про таблицю як не що інше, як набір рядків, які вона містить, неправильно, ІМО; таблиця є метаданими, а набір рядків ієрархічно приєднаний до таблиці, це не сама таблиця.

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

Насправді я завжди вважав популярним умову використовувати множинні назви таблиць. До цього моменту я завжди використовував множину.

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

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

SELECT * FROM cars WHERE color='blue'
SELECT * FROM car WHERE color='blue'

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

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

За іронією долі, я можу зробити Userвиняток і назвати його Usersчерез USER (Transac-SQL) , тому що мені теж не подобається використовувати дужки навколо столів, якщо мені не доведеться.

Мені також подобається називати всі стовпці ідентифікаторів як Id, ні ChickenIdабо ChickensId(що з цим роблять множини хлопців?).

Все це тому, що я не маю належної поваги до систем баз даних, я просто повторно застосовую знання з однієї хитрості-поні від OO іменування таких конвенцій, як Java за звичкою та лінню. Я хотів би, щоб була краща підтримка IDE для складного SQL.

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

SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'

Це врятувало наші душі в минулому - деякі наші системи баз даних пройшли 10+ років від SQL 6.0 до SQL 2005 - набагато минувши їх запланований термін.

Таблиці: множина

У таблиці користувачів вказано кілька користувачів.

Моделі: однина

З таблиці користувачів можна вибрати окремого користувача.

Контролери: множина

http://myapp.com/users перелічить декількох користувачів.

Це я все-таки беру на себе.

Я прихильник особливих назв таблиць, коли вони роблять мої діаграми ER за допомогою синтаксису CASE простішими для читання, але, читаючи ці відповіді, я відчуваю, що це ніколи не сприймалося дуже добре? Я особисто це люблю. Існує хороший огляд із прикладами того, наскільки читабельними можуть бути ваші моделі, коли ви використовуєте поодинокі назви таблиць, додаєте дієслова до ваших стосунків та формуєте хороші речення для кожного стосунку. Це все трохи надмірної кількості баз даних 20 таблиць, але якщо у вас є БД із сотнями таблиць і складною конструкцією, як ваші розробники коли-небудь зрозуміють це без хорошої читабельної схеми?

http://www.aisintl.com/case/method.html

Щодо префіксації таблиць і поглядів, я абсолютно ненавиджу цю практику. Не дайте людині взагалі ніякої інформації, перш ніж давати їм можливо погану інформацію. Кожен, хто переглядає db для об'єктів, може досить легко повідомити таблицю з виду, але якщо у мене є таблиця з назвою tblUsers, я чомусь вирішу переструктурувати в майбутньому дві таблиці, з метою об'єднання їх, щоб не порушити старий код Зараз у мене є вид з назвою tblUsers. На даний момент у мене залишаються два непривабливі варіанти, залиште подання, назване префіксом tbl, який може заплутати деяких розробників або змусити переписати інший шар, або середній рівень, або додаток, щоб посилатися на мою нову структуру або ім'я viewUsers. Це заперечує значну частину цінності поглядів на ІМХО.

Система tables/viewsсамого сервера ( SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, information_schema.columnsі т.д.) майже завжди під множині. Я думаю, що заради послідовності я б дотримувався їхніх результатів.

Якщо ми подивимось на MS SQL Server'sсистемні таблиці, то їх імена, призначені Microsoft, містяться в plural.

Системні таблиці Oracle названі в singular. Хоча декілька з них є множиною. Oracle рекомендує множину для визначених користувачем імен таблиць. Це не має особливого сенсу, коли вони рекомендують одне і слідувати іншому. Те, що архітектори цих двох програмних гігантів називали свої таблиці за допомогою різних умов, не має великого сенсу ... Зрештою, що це за хлопці ... кандидат наук?

Я пам’ятаю, в академіях рекомендація була єдиною.

Наприклад, коли ми говоримо:

select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'

може, b / c кожен IDобраний із певного одного ряду ...?

Це може бути трохи зайвим, але я б запропонував бути обережними. Не обов’язково, що погано перейменовувати таблиці, але стандартизація - це саме це; стандарт - ця база даних вже може бути «стандартизованою», але це погано :) - Я б запропонував узгодженість бути кращою метою, враховуючи, що ця база даних вже існує, і, імовірно, вона складається з більш ніж двох таблиць.

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

Практична послідовність іноді є найкращим стандартом ... :)

my2cents ---

Можливі альтернативи:

• Перейменуйте таблицю SystemUser
• Використовуйте дужки
• Зберігайте назви таблиці множини.

ІМО, що використовує дужки, є технічно найбезпечнішим підходом, хоча він трохи громіздкий. IMO це 6 з одного, півдесятка іншого, і ваше рішення дійсно просто зводиться до особистих / командних уподобань.

Моє взяття складається в семантиці залежно від того, як ви визначаєте контейнер. Наприклад, «мішок з яблуками» або просто «яблука» або «мішок з яблуками» або «яблуко».

Приклад: таблиця "коледж" може містити 0 або більше коледжів, таблиця "коледжів" може містити 0 або більше колег

a "student" table can contain 0 or more students 
a table of "students" can contain 0 or more students.

Мій висновок полягає в тому, що або це добре, але ви повинні визначити, як ви (або люди, що взаємодіють з ним), підходити під час посилання на таблиці; "таблиця сокири" або "таблиця xs"

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

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

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

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

Мені подобається використовувати префікси обмеженим чином (tbl для імен таблиць, sp_ для імен проц і т.д.), хоча багато хто вважає, що це додає безладу. Я також віддаю перевагу іменам CamelBack перед підкресленнями, оскільки під час введення імені завжди натискаю +, а не _. Багато інших не згодні.

Ось ще одне хороше посилання для іменування настанов щодо конвенції: http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

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

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

Я думаю, що наразі нахилююся до однини через множинні порушення в англійській мові. У німецькій мові це ще гірше через відсутність послідовних форм множини - іноді ви не можете зрозуміти, чи є слово множинним чи ні без вказаної статті перед ним (der / die / das). А в китайській мові все одно немає форм множини.

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

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

Я завжди думав, що це німа умова. Я використовую множинні назви таблиць.

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

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

лось-риба літальний олень ви штани шорти окуляри ножиці види потомство

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

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