![]() ![]() In order to achieve OO goal, then the easiest way is to change the plural into singular (in ERD/table naming convention). Contradiction comes when designing an ERD (that usually using plural naming convention - since one entity actually stores a set of entity), but a Class Diagram always using singular naming convention. I gotta go.Īgree with Alex, I think, since OO paradigm has a goal to unify terminology since requirement process until development process. I think I've convinced myself that I need to rename everything in my database. Outside, in whatever data-receiving language you may use, when manipulating a record as an entity, call the record instance by its singular. Within SQL, think of tables, and pluralize them. Perhaps the key here is to realize that, in general, we're not using SQL exclusively in most projects. My Hungarian tbl prefix eases the linguistic flinch I feel when I fail to find the 's' at the end of of my table name: I translate it to " the Part Table" "Table" becomes my pluralizing suffix. The table is a plural entity - a fact you run into when you think of the table itself, as you do when "thinking" in SQL. My records are instances of these classes. I chose the singular form for another reason: I look at a table as a class of identically-structured entities. I usually un-contrive them by using abbreviated aliases: SELECT Title FROM tblPart P WHERE. Presently I use singular names for my SQL tables, yet as mentioned, my SELECT statements seem contrived. Try to remember this trick now, old dog! :-) In Dutch we have a saying: ‘Do not compare apples to pears’. A DRD is a logical implementation of an ERD on a relational database in which the entities are the records and in which you are showing the relationships between the records that reside in tables, with the name of the tables correctly in plural form. ![]() What we also have to consider is that an ERD is not a DRD but a DRD is an ERD. When I use an ERD to describe the logical schema in a database I call it a DRD (Database Relationship Diagram). When I use an ERD to describe the logical implementation of it in an OO world I call it an ORD (Object Relationship diagram) or class diagram. I always use ERD’s for modeling data in a conceptual level. In my ERD diagrams I always use the singular names for entities also because of relationship readability. What I always say is that: ’a table is not an entity but withholds multiple entities and has therefore a plural name’. 2) Select Name FROM Employee WHERE Id IN (1,2) here you are selecting employees from an employee Not a nice syntax. 1) Select Name FROM Employees WHERE Id IN (1,2) here you are selecting employees from an employees data repository Ok, clear syntax. The SQL syntax is much clearer and logical when a table has a plural name. This is way I give tables always a plural name. Or is it tricks?Ībout this singular or plural question: I always take into account that a table in a database is not a single entity. Of course now the problem is getting an old dog to remember his new trick. ![]() So why not just name your entities appropriately in the first place: by making them singular? The objective of modeling is thus to express the relationship of a single entity (a workflow, an event, or whatever) to zero or one or many of another entity. Specifically, a workflow (singular) is initiated by one and only one event, and an event (singular) can initiate multiple workflows, as is expressed below: But Steve is extremely adamant about singular names for a different reason: because of relationship readability.įor instance, in Sharepoint, workflows relate to events. So why would one opt for singular names over plural ones?ĭevelopers might chose singular names because they are shorter and require less typing, but this argument never held for me because of tools like intellisense and code generation (not to mention touch typing). And for the second time now (see my post The Importance of a Logical Data Model), it was a colleague: Steve Dempsey who initiated the change. There’s no reason for this convention, other than perhaps I copied what I saw from the Northwind database.īut it’s important to question these practices from time to time, and after over seven years of doing things the same way I have decided to make a change. It seems as though as software developers mature they develop consistency in their approach to just about every aspect of their work, regardless if there is a good reason for adopting a particular practice or not.įor instance, in data modeling I developed the habit of always naming my tables in the plural – Employees instead of Employee, and such. ![]()
0 Comments
Leave a Reply. |