Saturday, February 25, 2012

Best Design Practice?

I'm building a database that has maybe four unique tables Student,
Advertiser, Employee, maybe Account. Three of the four table (Student,
Advertiser, Employee) have something in common in which they all contain
fields such as emailAddress, password, role, isAccountActive, etc. which
allow them to access their respected data. However, is it best practice to
build a fourth table which contain Account information or should I just
include that information in their respected tables?

My thinking is that if you have a fourth table such as Account then you can
manage all accounts (Student, Advertiser, Employee) from one table, but as
the database gets more in-depth you have to build more and more complex
stored procedure to do simply task such as update, delete, select, etc.i would probably combine all 4 tables into one because of the columns the first three have in common

it really depends on how many columns they don't have in common|||try reading this.

Database Design for Mere Mortals (http://www.amazon.com/gp/product/customer-reviews/0201752840/102-7659258-1375352?_encoding=UTF8&me=ATVPDKIKX0DER&s=books)|||in addition, i truly beleive that the data model is entirely indicative of the business model or in other words, the data model already exists it's your job to discover it.

the rules are defined as a dictum for all to follow. some follow them more strictly than others and some bend the rules to accomodate performance and simplicity requirements.

as a designer, you should know the rules before you can intelligently break them.|||the rules are defined as a dictum for all to follow. some follow them more strictly than others and some bend the rules to accomodate performance and simplicity requirements.you'll love this discussion, then --

http://www.kottke.org/04/10/normalized-data

by the way, i trust that remark about making an attempt to read a web page on amazon was not directed at me :)|||you'll love this discussion, then --

http://www.kottke.org/04/10/normalized-data

by the way, i trust that remark about making an attempt to read a web page on amazon was not directed at me :)

what the hell are you talking about?

by the way i read your link and that is just another example of a application developer assuming that he has the chops for db work. just because you can type create table create view and creat proc , in no way makes you a dba it just makes us all look bad when the shiat hits the fan and said app developer cant fix it.
I hate this subject so much that just a 5 minute exposure to this article has totaly pissed me off.

"ooooooohhh i hate that rabbit"|||what the hell are you talking about?i was talking about your comment in post #3 which immediately followed my post #2 -- i assume your rather arrogant comment "try reading this" wasn't directed at me

you should read that kottke article a little more closely, it is the comments to the article that are all the fun, kottke himself is not a dba, he was just raising the issue

if the name kottke means nothing to you, that's fine, i guess you haven't been around the web much

the name cal henderson may not mean anything either, but he is the one who developed the back end for flickr, and you really should read his powerpoint presentation, flickr is an amazing project and i personally don't have th chops to do anything remotely like that

maybe you do, though

:)|||R2D2.

against my better judgement, I will issue the following statement.

my initial post was directed to the guy who started this thread.
my follow up post was a kind of postscript to the previous post and once again was directed to the guy who started this thread

at no point were you even on my radar.|||I just want to thank you guys for the help. I have now made a sound decision on my database design.|||...and off to the holy quest, to seek the holy model...

...and sometimes our heated discussions remind me of this opening scene (http://www.mwscomp.com/movies/grail/grail-01.htm)...|||at no point were you even on my radar.oh, that's so adult of you, rupert|||Neutral corners, please!

No comments:

Post a Comment