Вопрос: Дилемма имен таблиц: сингулярные и множественные имена [закрыты]


Academia утверждает, что имена таблиц должны быть единственными сущностями, в которых хранятся атрибуты.

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

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

Мне остаться или идти?


1151


источник


Ответы:


Другие дали довольно хорошие ответы, поскольку «стандарты» идут, но я просто хотел добавить это ... Возможно ли, что «Пользователь» (или «Пользователи») на самом деле не является полным описанием данных, хранящихся в таблице ? Не то, чтобы вы были слишком сумасшедшими с именами таблиц и спецификой, но, возможно, что-то вроде «Widget_Users» (где «Виджет» - это имя вашего приложения или веб-сайта).


202



У меня был такой же вопрос, и после прочтения всех ответов здесь я определенно остаюсь с СИНГУЛЯРНЫМ, причины:

Причина 1 (Концепция). Вы можете думать о сумке, содержащей яблоки, такие как «AppleBag», неважно, содержит ли она 0, 1 или миллион яблок, это всегда одна и та же сумка. Таблицы таковы, что контейнеры, имя таблицы должны описывать, что она содержит, а не то, сколько данных она содержит. Кроме того, концепция множественного числа больше относится к разговорной речи (фактически, чтобы определить, есть ли один или несколько).

Причина 2 , (Удобство). легче выходить с единственными именами, чем с множественными. Объекты могут иметь нерегулярные множественные числа или множественное число, но всегда будут иметь единственное (за некоторыми исключениями, например, News).

  • Клиент
  • порядок
  • пользователь
  • Положение дел
  • Новости

Причина 3 , (Эстетика и порядок). Специально в сценариях master-detail это лучше читается, лучше выравнивается по имени и имеет более логичный порядок (сначала мастер, второй деталь):

  • 1.Order
  • 2.OrderDetail

В сравнении с:

  • 1.OrderDetails
  • 2.Orders

Причина 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, ...

Или используйте печально известные квадратные скобки [Пользователь]


1347



Если вы используете инструменты реляционного сопоставления объектов или я буду в будущем предлагаю Единственное число ,

Некоторые инструменты, такие как LLBLGen, могут автоматически корректировать множественные имена, такие как пользователи для пользователя, без изменения самого имени таблицы. Почему это имеет значение? Потому что, когда он отображается, вы хотите, чтобы он выглядел как User.Name, а не Users.Name или хуже из некоторых моих старых таблиц баз данных, называющих tblUsers.strName, которое просто путается в коде.

Мое новое эмпирическое правило состоит в том, чтобы судить о том, как оно будет выглядеть, когда оно будет преобразовано в объект.

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


240



I prefer to use the uninflected noun, which in English happens to be singular.

Inflecting the number of the table name causes orthographic problems (as many of the other answers show), but choosing to do so because tables usually contain multiple rows is also semantically full of holes. This is more obvious if we consider a language that inflects nouns based on case (as most do):

Since we're usually doing something with the rows, why not put the name in the accusative case? If we have a table that we write to more than we read, why not put the name in dative? It's a table of something, why not use the genitive? We wouldn't do this, because the table is defined as an abstract container that exists regardless of its state or usage. Inflecting the noun without a precise and absolute semantic reason is babbling.

Using the uninflected noun is simple, logical, regular and language-independent.


161



What convention requires that tables have singular names? I always thought it was plural names.

A user is added to the Users table.

This site agrees:
http://vyaskn.tripod.com/object_naming.htm#Tables

This site disagrees (but I disagree with it):
http://justinsomnia.org/writings/naming_conventions.html


As others have mentioned: these are just guidelines. Pick a convention that works for you and your company/project and stick with it. Switching between singular and plural or sometimes abbreviating words and sometimes not is much more aggravating.


115



How about this as a simple example:

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

vs.

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

The SQL in the latter is stranger sounding than the former.

I vote for singular.


54



I am of the firm belief that in an Entity Relation Diagram, the entity should be reflected with a singular name, similar to a class name being singular. Once instantiated, the name reflects its instance. So with databases, the entity when made into a table (a collection of entities or records) is plural. Entity, User is made into table Users. I would agree with others who suggested maybe the name User could be improved to Employee or something more applicable to your scenario.

This then makes more sense in a SQL statement because you are selecting from a group of records and if the table name is singular, it doesn't read well.


52



I stick with singular for table names and any programming entity.

The reason? The fact that there are irregular plurals in English like mouse ⇒ mice and sheep ⇒ sheep. Then, if I need a collection, i just use mouses or sheeps, and move on.

It really helps the plurality stand out, and I can easily and programatically determine what the collection of things would look like.

So, my rule is: everything is singular, every collection of things is singular with an s appended. Helps with ORMs too.


34



Singular. I don't buy any argument involving which is most logical - every person thinks his own preference is most logical. No matter what you do it is a mess, just pick a convention and stick to it. We are trying to map a language with highly irregular grammar and semantics (normal spoken and written language) to a highly regular (SQL) grammar with very specific semantics.

My main argument is that I don't think of the tables as a set but as relations.

So, the AppUser relation tells which entities are AppUsers.

The AppUserGroup relation tells me which entities are AppUserGroups

The AppUser_AppUserGroup relation tells me how the AppUsers and AppUserGroups are related.

The AppUserGroup_AppUserGroup relation tells me how AppUserGroups and AppUserGroups are related (i.e. groups member of groups).

In other words, when I think about entities and how they are related I think of relations in singular, but of course, when I think of the entities in collections or sets, the collections or sets are plural.

In my code, then, and in the database schema, I use singular. In textual descriptions, I end up using plural for increased readability - then use fonts etc. to distinguish the table/relation name from the plural s.

I like to think of it as messy, but systematic - and this way there is always a systematically generated name for the relation I wish to express, which to me is very important.


28



I also would go with plurals, and with the aforementioned Users dilemma, we do take the square bracketing approach.

We do this to provide uniformity between both database architecture and application architecture, with the underlying understanding that the Users table is a collection of User values as much as a Users collection in a code artifact is a collection of User objects.

Having our data team and our developers speaking the same conceptual language (although not always the same object names) makes it easier to convey ideas between them.


19