Customer or Customers?
-
Hello Gurus!
Once and for all... Should I use singular or plular form in table names? I read some articles about naming conventions but they are clashing. So, what do you say, is it Customer or Customers?
And one thing about bridge tables. How do I name a bridge table between "Themes" and "ThemeCategories"? ThemeThemeCategories?
/Tomi
-
Personally, I prefer singular (Customer).
1) It's shorter
2) Sounds right. I have 1 Customer record. I have 200 Customer records.
q2 => I think you'd have Theme, Category, AND ThemeCategory!
Darren
Darren -
Thanks Darren!
quote:
q2 => I think you'd have Theme, Category, AND ThemeCategory!
Ah! But I can't rename the ThemeCategory table to Category! See, I have ForumGategory, GroupCategory and so on...
Eg. this is my ThemeCategories table:
ThemeCategories
thmID
Name
Description
And I need a table like this:
InsertNiftyNameHere
thmID
catID
It's just a bridge (aka junction, middle, associative, or connector) table. Maybe I could name it ref_ThemeCategory or something like that? I bet many of you have more experience than I with table naming... so, please, help me out!
Thanks!
/Tomi
-
As you mentioned yourself, naming conventions are a personal thing. The best advice is to define/choose a naming convention and stick to it.
For me, singular names work best, and I would think about merging the different 'category' tables, maybe adding a 'categorytype' column. That way, you share common functionality of the 'category' tables and your naming gets a lot easier
.If that's not possible, you could think about ThemeCategoryTheme, which makes more sense...
-
quote:
...about merging the different 'category' tables, maybe adding a 'categorytype' column. That way, you share common functionality of the 'category' tables and your naming gets a lot easier.
Now, that's a great idea! It would save disc space and I would only need one Category table! But wouldn't it complicate my queries? And I'm having trouble with JOINing two tables!
/Tomi
-
The queries wouldn't get that much more complicated. Just add an additional WHERE clause to select the correct type when joining.
You are correct with your remark for the Foreign keys. You cannot enforce referential integrity so that a certain Theme only points to a category of the Theme-type.
-
Hi,
as mentioned above, naming convention are mainly personal preferences, but if but develop in a team it can be quite *funny*, if each developer uses his own convention. In this situation you should seek to find a common level among the team and then stick to it.
Cheers,
Frank
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
Thanks guys!
I came up with this solution:
I renamed the original ThemeCategories table to ThemeCategoryInfo and the bridge table to ThemeCategories...
And BTW, it isn't impossible to change the names later on.
/Tomi
-
Later changes sometimes get ignored because it just not worth the effort, front end, middle tier, back end, etc. I think I'll stick with NPeeters post. Do it 'right' the first time, a level of satisfaction acceptable to most of the users of the database.
-
Thanks for your input, 5409045121009 (what's with the name, anyways? Is it a code or something?)
You're right, I'll have to think about the names again before I start writing procedures. I don't care about the index names - they're pretty easy to find with the Enterprise Manager.
/Tomi
Edited by - tomiz on 05/20/2003 08:21:32 AM
.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply