dim schema or DimTableName
3 posters
Page 1 of 1
dim schema or DimTableName
Hi, I came across a post the other day on http://arcanecode.com/, it's about date dimensions but my question is about a naming convention talks about (briefly). he uses a "dim" schema so tables are dim.Date rather than dbo.DimDate or whatever.
I hadn't really thought about using this approach, but it's appealing. I'm working with a group right now, who still uses a lot of SQL and all the dim_customer and dim_date seems tedious.
I know they should be using a UI.
anyone have any strong negatives around using schemas, or what are people doing? not even bothering with dimTableName and just go with tablename. interested to hear.
thanks for reading
robert
I hadn't really thought about using this approach, but it's appealing. I'm working with a group right now, who still uses a lot of SQL and all the dim_customer and dim_date seems tedious.
I know they should be using a UI.
anyone have any strong negatives around using schemas, or what are people doing? not even bothering with dimTableName and just go with tablename. interested to hear.
thanks for reading
robert
Re: dim schema or DimTableName
Seems like overkill. And, who exactly, is a set up like that supposed to benefit? Certainly not the users.
I've been at this for a long time and I could never figure out what the benefit was of elaborate naming schemes to classify tables. Maybe its inherent in our nature as modelers. But it seems to me, a decent modeler should be able to tell the difference between a fact and dimension table by looking at it. I like to use names like: Dates, Customers, Products, etc... That should be enough to know its a dimension.
Their can be technical reasons in extreme cases to distribute tables into different schema, usually to make backup and restore easier for very large tables, but you usually wind up building a 'user' schema with synonyms and views so the whole looks like one environment.
I've been at this for a long time and I could never figure out what the benefit was of elaborate naming schemes to classify tables. Maybe its inherent in our nature as modelers. But it seems to me, a decent modeler should be able to tell the difference between a fact and dimension table by looking at it. I like to use names like: Dates, Customers, Products, etc... That should be enough to know its a dimension.
Their can be technical reasons in extreme cases to distribute tables into different schema, usually to make backup and restore easier for very large tables, but you usually wind up building a 'user' schema with synonyms and views so the whole looks like one environment.
Re: dim schema or DimTableName
Thanks, that makes sense. I like the simple names approach as well, but I've seen a lot of examples of prefixing with "dim". Usually there's a UI on top and no one sees these names (it shows simple descriptive names), but because I'm back in SQL the prefix stands out as noise.
Re: dim schema or DimTableName
I don't get it either. Isn't the benefit of using different Schemas is it allows easier security controls? Is there any other benefit? Because if not, I don't see how seperating fact from dimensions by schema has any benefit.
Jeff Smith- Posts : 471
Join date : 2009-02-03
Re: dim schema or DimTableName
Schemas have many features/benefits, with security being a primary use case, but at it's core it's a name space so not restricted to that.
Similar topics
» Start Schema vs Snow flake schema
» DWT 2nd ed insurance schema
» Dimension loading sources
» Snowflake or Star Schema?
» star schema designing
» DWT 2nd ed insurance schema
» Dimension loading sources
» Snowflake or Star Schema?
» star schema designing
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum