Множина проти назви одиничного числа

Як я повинен називати свої таблиці під час створення нової бази даних?

Однини: Clientчи множини Clients:?

До вас. Просто будьте послідовні, хоча.

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

Це відповідає моєму моделюванню (за допомогою моделювання рольових об'єктів), де я використовую особливі сутності / типи.

Редагувати:

Однією з причин є те , що множина зазнає невдачі , коли у вас є таблиці посилань:
Orders, Productsдав би OrderProductsабо OrdersProducts. Ні звуки правильні

Або таблиці історії (звичайно, ви можете використовувати схеми для цього):
Orders-> OrdersHistoryабо (ні!) OrdersHistories? Чи не Order-> OrderHistoryкраще?

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

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

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

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

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

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

Так само , як @ ГБН - х Відповідь я думаю , що це саме питання переваг і так само , як він , я рекомендую , щоб будь-який вибір ви зробили, застосовувати його скрізь (в тому , що БД , по крайней мере). Консистенція того варта.

Однак моя перевага полягає в тому, що множина краще звучить у SELECTвисловлюваннях:

SELECT Id, Name, Status 
FROM   Persons
WHERE  Status <> 5  --5 meaning deleted

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

"замовлення" - це застережене слово. "наказів" немає

"користувач" - це застережене слово. "користувачів" немає

"сесія" - це застережене слово. "сеансів" немає

"результат" - це застережене слово. "результати" немає

"родич" - застережене слово. "родичів" немає

...

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

Я вважаю, що таблиця SQL повинна містити множинні імена. Він просто читає набагато краще.

Таблицю книжкових записів слід називати книгами. ORM має використовувати ту саму конвенцію. Об'єкт «Книги» - це колекція, яка очолює всі записи в таблиці Книг. Об'єкт Книги головує над одним записом.

Це робить кодування більш природним.

select name, publication_date from books where publication_date > '2000-01-01';

books = Books()
for book in books.get("publication_date >= '2000-01-01'"):
    print book.name

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

Це дуже особиста річ. Я використовую єдину форму вже 30 років. Але я бачу, чому людям подобається множина. Книги - автори цікаві, тому що я думаю, що автори книги не помиляються. Книга може мати одного або декількох авторів. І автори, можливо, написали одну чи декілька книг (наприклад, у співавторстві). Це також просто залежить від того, як ти поводишся з книгами, написаними більш ніж одним автором. Я згоден з іншими відповідями; виберіть один і будьте послідовними. Що стосується застережених слів. Я думаю, що важко придумати імена для вирішення проблем. користувач -> app_user, сеанс -> app_session, замовлення -> customer_order

Ми розглядаємо речі з різних точок зору, і я думаю, що два табори визначені:

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

Тож "контейнер користувача" може містити кілька рядків.

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

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

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

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

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

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