Singular or Plural
-
Comments posted to this topic are about the item Singular or Plural
-
I started off plural and ended up singular too!!
Is there a parallel here with being socialist when you're young and conservative when you're old perhaps - or have I become overly politicised recently! -
Singular is less typing. Clarity of intent trumps all.
When working with Python we use Flake8 as a style cop. The beauty of using a mechanical style cop is that the standards are always enforced. You cannot argue with a machine so it takes personality out of the equation and moves the conversation on to those points that are of relevance.
I would push back on anything that prefixes an object to tell you what type of object it is such as tbl, vw, fn, usp etc.
-
If you look anywhere outside of the database world, I'm pretty sure you'd get a pretty unequivocal answer: You have, for example, a number of objects/structures/tuples/rows that are manifestations of a class/type/schema/whatever, such as Person. Storing those in a collection/set/array variable and naming that variable "person" would make any right-minded coder uneasy. Clearly that's a "persons" variable to denote the plurality of the contents. One of the items would be stored in a "person" variable.
Now, I'll confess to drifting more to the singular naming when I do mainly relational database stuff, and then revert back to plural when I get into other environments. And I can't see it is much of a real problem, other than when auto generating data access objects from a database schema.
I suppose one of the reasons for this is that a well behaved relational database developer always treats things as sets with multiple rows in them, even if that multiple is sometimes 1.
Just because you're right doesn't mean everybody else is wrong. -
I would say:
* It doesn't matter very much.
* For me a table is a collection of X; so I use plural, just as I would for a list or an array in any other programming language. Similarly if I have a stored procedure designed to get a single value/row I use singular whereas if it gets multiple rows I use a plural. -
singular
-
I think without thinking I'd use plural out of habit, but I do think that singular makes more sense at the database side, and plural when you have your Lists and Arrays in your app code.
But as ever consistency beats all, if the existing database objects use plural, then so do you.
-
I agree consistency is the important thing; it's helpful to know what a table is called without having to look up whether it's singular or plural. It's singular for me (after being plural for a long time too). Reasons I'm swayed that way are that:
a) plurals can be inconsistent
b) ORM usage - ORMs will create models that contains collections, the collections are easily distinguished if they are plural, and the entities created are singularb) may be only a spin on what Steve said but it's helpful if you do use EF or similar.
-
I use singular, because that was the way I was taught originally. Like several of the others I think consistency (within a system or application) is more important than which you choose. Some of the comments along the lines of "singular for the database and plural for collections elsewhere" have made me pause to think though.
Tom Gillies LinkedIn Profilewww.DuhallowGreyGeek.com[/url]
-
I've used both, and which I choose depends on the nature of the product using the database. I want the developers to find writing queries against my schema easy, so as well as naming objects so that they naturally group together in the object tree, harder than it sounds if you want to keep it readable, I select names that make writing queries easy.
If the main use is to be OLTP, such as order and stock control, then names of Customer, Address, Order, OrderDeliveryAddress all make sense. But do you choose OrderItem or OrderItems? I say "For each Item in OrderItems" so I may want to use plural there, but some people will say "For each OrderItem" and I am likley to stick to this if all of the other tables use singular nouns. It makes thinking of the process of looking up the details or order history of one particular customer easy.
But if processing is likely to be more set based then plurals make more sense as having Customers, Orders, and OrderItems helps me think in a set based way for those times when we are writing queries for all Customers, or all Orders.
Yes this may mean that the reporting DB has different (but related) names to the live ordering system, it shows that it is intended for a different purpose and, hopefully, guides users and developers into the correct mindset to query each. -
A clear consensus is "consistency". I started developing in CP/M days, with Cobol. Each table was it's own file on disk, therefore the 8.3 naming convention was mandatory! We coded the table names based on module, e.g. SLCU = Sales Ledger Customer File, PLSU = Purchase Ledger Supplier File. When I moved to SQL, I flopped around a bit because the extras characters available jarred with my habits. Eventually I settled on plural for tables (database), singular for classes (coding) - based around the DHH's Ruby-on-Rails mantra "convention over configuration". Though I don't use Rails, I've found that concept helpful, as you can "guess" object names (tables, columns, classes) when writing instead of always having to look them up.
-
When I first started, it was singular all the way. Then I discovered the problem with it. Reserved words. You have to work to not use reserved words. Look at an Order table. That's a reserved word so you have to use something like CustOrder or cOrder, etc. That's just extra useless typing... just use Orders and it's not only intuitive, but it keeps you just having to contrive a prefix that either doesn't make sense or is redundant. I mean, who else would place an order, of course it's a customer!
I also don't think that consistency is necessary. I think it's more important to name objects in the way people think of them. However the main users view the data is going to be the easiest way for them to query it and it'll make sense to them. So do that. If that means that some tables are plural and some are singular then ok. Do that.I studied formal modeling so I get the singular argument, but don't forget it's all made up anyway. From a modelers perspective, it helps to think of everything as a single entity, but once it becomes an actual DB, nobody else thinks like that. So why force modeling rules onto your users? And if a modeler looks at an Orders table and thinks that each row holds multiple orders then he's just dumb and doesn't deserve to be modeling your DB. This is all made up people. And there are few actual modelers anymore. I used the singular naming scheme for years but I just got tired of coming up with unnatural names to get around reserved words.
Besides, if you want to talk about consistency, just take a look at some of my tables for my Minion Maintenance products. I have a Log table and a LogDetails table. The log table holds an overview log of how the overall job went. The LogDetails table holds details for individual records. It doesn't hold just 1 detail, it holds dozens. But the Log table only holds a single log for each run. And while we can get bogged down in a discussion that the LogDetails table holds only one detail row per object, that's unnatural. When you talk about it you say, can I see the details for this specific index rebuild... you don't say can I see the detail?
So since the rules are all made up, and it's clearly not a performance thing, do whatever you like, and give your tables nice, natural names. Don't worry about consistency. Worry about being natural and make a nice DB.
Watch my free SQL Server Tutorials at:
http://MidnightDBA.com
Blog Author of:
DBA Rant – http://www.MidnightDBA.com/DBARantMinion Maintenance is FREE:
-
First, it doesn't matter much.
Second, when I get to design to my naming convention, I use singular. Primarily because it's less typing, but secondarily because it's what the entity is. -
For Business Intelligence purposes, Alberto Ferrari and Marco Russo (The Italians) suggest singular names like Customer for Dimension tables, and plural names like Sales for Fact tables. Page 20 of Analyzing Data with Microsoft Power BI and Power Pivot for Excel.
-
I used to use plural for tables, since a table is a collection--but that reasoning falls down somewhat when you actually consider what a table is.
A table is an OBJECT, a singular object. It consists of columns, not rows. An empty table has no rows, but it does have columns. Therefore it is reasonable (and logical) to name tables as singular rather than plural. Especially when considering the RBAR mantra... (waving at Jeff)
On the application side, however, it's a completely different animal. SQL is set based, i.e. a set of rows (result set) is one thing. But a collection is by its nature plural and is always processed with a loop, each time through the loop dealing with one row. Therefore a collection is plural.
On the SQL side singular has a number of advantages. If all tables are named in the singular then you eliminate the complexities of English plurals right off the bat, therefore it reduces memory load during development, as many posters have pointed out.
Also, it's simple enough to avoid the reserved word problem by consistently using square brackets to name user created objects like tables and column names. (And yes, I know that's another serious cat fight where I'm absolutely in the minority 😛)
In the end, the point of standardized naming conventions (whichever ones you choose) is predictability. It's to relieve you of the need of remembering exact details, it reduces cognative load on the developer/dba/architect/chief cook and bottle washer.
Oh, and tabs vs. spaces? Spaces, here, but absolutely get a text editor that's not stupid, one that converts the tab key to the correct spaces! :hehe:
Viewing 15 posts - 1 through 15 (of 81 total)
You must be logged in to reply to this topic. Login to reply