ordinal position of columns in tables
3 posters
Page 1 of 1
ordinal position of columns in tables
Hi All,
We have an argument going on about the position of columns in FACT and Dimension tables. I want to keep surrogate keys on the top and then BKssss. Also want to group logicallay related fields First_name, last_name etc together in dimensions. In fact tables I want all SK on the top, them facts and then any timestamps. My developers argue and say this has has no relevance. They want to put fields in random order and create views on top the table to bring these fields in-order. So they suggest tables like this,
DIM_EMPLOYEE
HASH_VALUE
EMPLOYEE_PHONE
FIRST_NAME
ADDRESS
EMPLYEE_ID_SK
MIDDLE_NAME
EMPLYEE_ID_BK
now as per them other dimensions can have different order. So there is no particular pattren to follow.
As an architect, I am big believer of embedding quality in the systems right from the begining, so I want to order them in the tables.. Please, comment...
We have an argument going on about the position of columns in FACT and Dimension tables. I want to keep surrogate keys on the top and then BKssss. Also want to group logicallay related fields First_name, last_name etc together in dimensions. In fact tables I want all SK on the top, them facts and then any timestamps. My developers argue and say this has has no relevance. They want to put fields in random order and create views on top the table to bring these fields in-order. So they suggest tables like this,
DIM_EMPLOYEE
HASH_VALUE
EMPLOYEE_PHONE
FIRST_NAME
ADDRESS
EMPLYEE_ID_SK
MIDDLE_NAME
EMPLYEE_ID_BK
now as per them other dimensions can have different order. So there is no particular pattren to follow.
As an architect, I am big believer of embedding quality in the systems right from the begining, so I want to order them in the tables.. Please, comment...
Last edited by DilMustafa on Thu Jul 16, 2009 3:38 pm; edited 1 time in total
DilMustafa- Posts : 49
Join date : 2009-02-03
Location : Calgary, Canada
Re: ordinal position of columns in tables
Stick to your guns... It certainly makes sense to try to keep them in some logical order, at least when you are creating the tables for the first time. Why anyone would try to argue otherwise doesn't make sense. Of course, problem is, you can't maintain that structure once the table goes into production as future changes (via alters) puts the columns at the end. A minor issue, but at least most fields will be easy to find.
Re: ordinal position of columns in tables
Absolutely, check out the discussion on this some months ago http://forum.kimballgroup.com/dimensional-modeling-and-data-architecture-f6/adding-new-attributes-to-a-dimension-t44.htm
I'm not sure my point was really understood at the time, but anyone who uses a schema browser just knows that what you're suggesting makes sense from a data interpretation and checking standpoint which in your role equates to usability.
I'm not sure my point was really understood at the time, but anyone who uses a schema browser just knows that what you're suggesting makes sense from a data interpretation and checking standpoint which in your role equates to usability.

» Number of Columns in Fact Tables vs. Dimension Tables
» Is it a must for FACT tables to have all its FKs columns form the Primary Key ?
» Not drinking the Kool Aid
» Sorting / Ordinal for dimension status attribute
» How many columns is too many OR how to reduce the columns
» Is it a must for FACT tables to have all its FKs columns form the Primary Key ?
» Not drinking the Kool Aid
» Sorting / Ordinal for dimension status attribute
» How many columns is too many OR how to reduce the columns
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum