ordinal position of columns in tables

[DilMustafa]

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...

[ngalemmo]

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.

[robhale]

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.

[Sponsored content]