<a href="http://g.adspeed.net/ad.php?do=clk&zid=15220&wd=468&ht=60&pair=as" target="_blank"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15220&wd=468&ht=60&pair=as" alt="i" width="468" height="60"/></a>
Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
<a href="http://g.adspeed.net/ad.php?do=clk&zid=15491&wd=120&ht=300&pair=as" target="_top"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15491&wd=120&ht=300&pair=as" alt="i" width="120" height="300"/></a>
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
Article Discussions
»
Article Discussions by Author
»
Discuss content posted by Paul White
»
An Introduction to Database Design
126 posts, Page 2 of 13
««
1
2
3
4
5
»
»»
An Introduction to Database Design
Rate Topic
Display Mode
Topic Options
Author
Message
suntec
suntec
Posted Tuesday, January 18, 2011 7:02 AM
Grasshopper
Group: General Forum Members
Last Login: Tuesday, February 19, 2013 9:13 PM
Points: 16,
Visits: 39
Its an awesome article I came across in recent past for freshers. I have suggested many freshers to see this article for understanding the table design.
Nice example to demonstrate the complete idea of designing table.
Great Work!!!
Post #1049309
sharath.chalamgari
sharath.chalamgari
Posted Tuesday, January 18, 2011 7:16 AM
Ten Centuries
Group: General Forum Members
Last Login: Monday, September 17, 2012 7:30 AM
Points: 1,038,
Visits: 679
Good Work Paul!
I haven't seen any article that explains the database designing concepts like a story,easy to understand format.
Post #1049324
Chris Houghton
Chris Houghton
Posted Tuesday, January 18, 2011 7:32 AM
Mr or Mrs. 500
Group: General Forum Members
Last Login: Thursday, May 16, 2013 9:12 AM
Points: 557,
Visits: 1,356
Nice work!! It's often said that to truly understand a concept you should be able to explain it to others in simple terms and you've definitely done that with this article. Simplicity to the point of brilliance. I shall refer to this when explaining database design concepts to customers.
Post #1049341
kenambrose
kenambrose
Posted Tuesday, January 18, 2011 8:01 AM
Valued Member
Group: General Forum Members
Last Login: Monday, May 13, 2013 8:13 AM
Points: 70,
Visits: 413
I believe there are some serious flaws in this article. For example, recepts represent a historical record of a transaction occuring in a moment in time.
If one normalizes the customer as is done in this example, and simply uses a foreign key in each receipt, what happens if a customer changes their address at some later time? or name? (people do get married).
Now, ALL of the historical receipts return the NEW address or customer name, not the address or name of record at the time of the sale.
This can't be correct, and would get most businesses in serious legal trouble. And I personally have seen this type of nonsense in many amateurish attempts at normalization.
This presentation is oversimplified to the point of providing poor instruction I am afraid...
Post #1049369
kenambrose
kenambrose
Posted Tuesday, January 18, 2011 8:07 AM
Valued Member
Group: General Forum Members
Last Login: Monday, May 13, 2013 8:13 AM
Points: 70,
Visits: 413
I should dd that bob's original paper receipts were MORE accurate than the DB design offered. At least the paper receipts would always return accurate info for the customer for the moment in time the sale was completed....
Post #1049374
mike_walsh
mike_walsh
Posted Tuesday, January 18, 2011 8:08 AM
SSC Journeyman
Group: General Forum Members
Last Login: Friday, January 11, 2013 9:05 AM
Points: 89,
Visits: 408
Ken - I think you missed the "An Introduction". You bring up some points that would be a good follow on article. Why don't you write up an article that follows on to Paul's but adds some more advanced concepts and continues to explain them in a simple way. I'd love to see a part two.
__________________________________________________
Mike Walsh
SQL Server DBA
Blog -
www.straightpathsql.com/blog
|
Twitter
Post #1049375
casinc815
casinc815
Posted Tuesday, January 18, 2011 8:13 AM
Grasshopper
Group: General Forum Members
Last Login: Friday, January 11, 2013 8:29 AM
Points: 22,
Visits: 48
Paul:
Great primer. Showed it to some of my staff and have been able to raise the curiosity level so we can move away from spreadsheets. Once again, great article.
Jim
Post #1049378
kenambrose
kenambrose
Posted Tuesday, January 18, 2011 8:33 AM
Valued Member
Group: General Forum Members
Last Login: Monday, May 13, 2013 8:13 AM
Points: 70,
Visits: 413
re. Inroduction. Well I suppose it depends on what you feel are the "fundamentals" of our work in DB design. Personally, concepts such as natural business keys (the author jumps right into physical issues ala surrogate keys and misses this concept completely), historical record keeping concepts, etc. ARE the fundamentals, from my experience as a trainer.
I just think this is a primer based on someone's mixing up physical with conceptual and logical DB issues- a serious flaw that is the bane of our industry in my opinion...
ken
Post #1049404
mtassin
mtassin
Posted Tuesday, January 18, 2011 8:45 AM
Hall of Fame
Group: General Forum Members
Last Login: Today @ 9:42 PM
Points: 3,226,
Visits: 64,144
kenambrose (1/18/2011)
I believe there are some serious flaws in this article. For example, recepts represent a historical record of a transaction occuring in a moment in time.
If one normalizes the customer as is done in this example, and simply uses a foreign key in each receipt, what happens if a customer changes their address at some later time? or name? (people do get married).
This isn't an instruction manual to type 2 SCDs, I'd consider this a typical approach to an OLTP system. The whole purpose of a database like this is that if a customer's data changes that we minimize updates to correct data.
If Paul were writing an article on the basics of designing a data warehouse, then he could cover handling the type 2 SCD here in the ETL process, though I think this would be over Bob's head.
But I've seen too many multi-million dollar ERP databases handle this sort of customer record as "present value" exactly this way to completely discount it.
And if the customer data has changed enough, a new customer record could be created with a foreign key chaining in the same table to point the old record to the new.
--Mark Tassin
MCITP - SQL Server DBA
Proud member of the Anti-RBAR alliance.
For help with Performance click this link
For tips on how to post your problems
Post #1049418
kenambrose
kenambrose
Posted Tuesday, January 18, 2011 8:49 AM
Valued Member
Group: General Forum Members
Last Login: Monday, May 13, 2013 8:13 AM
Points: 70,
Visits: 413
re. new customer record. And there is no unique index on the business key. So as a result, an unlimited number of exact duplicate customer records could also be created from the design.
I don't know about you but that is exactly the type of nonsense I see repeatedly in the field when people who do not understand the basic concepts of DB design attempt it.
My statement stands. Bob's orignal paper record keeping is more accurate than the DB design presented...
Post #1049424
« Prev Topic
|
Next Topic »
126 posts, Page 2 of 13
««
1
2
3
4
5
»
»»
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.
