Design Your Own Database (2004) [pdf]
dartmouth.edu
Design Your Own Database (2004) [pdf]
1–9 of 9 posts
Re: Design Your Own Database (2004) [pdf]
#2Well said about planning with a pen and paper.
Re: Design Your Own Database (2004) [pdf]
#3Going up a couple levels to here: http://www.dartmouth.edu/~bknauff/dwebd/index.html is kind of an interesting snapshop of where the world was a decade ago.
Dartmouth is a weird place, though. Until quite recently, people didn't really text or use cellphones on campus, instead relying on an incredibly ugly email client that ran on a custom protocol called BlitzMail[1].
Re: Design Your Own Database (2004) [pdf]
#4Does anyone still do this(database design)?
(sarcasm here with a bad taste ebcause I might be wrong in my belief ... and I want to be right that the articla info is used by everyone(or at least the majority) in the software development filed but have my doubts ... way too many doubts).
With all the paradigms - agile and etc. , gazilion of frameworks in all the different languages, the complete avoidance of database lock-in, the lack of database architect roles on job boards(I see only dba and database developer roles). One might say that database developers are responsible for this but most of the time I see that it's actually the java/php and other fourth generation language devs that are the sole db developers in the company. In the end they are the ones who make the mess in the database over the years ... and at this point in time there is no practical way back.
It's so depressing ...
Re: Design Your Own Database (2004) [pdf]
#5Does anyone still do this(database design)? (sarcasm here with a bad taste ebcause I might be wrong in my belief ... and I want to be right that the articla info is used by everyone(or at least the majority) in the software development filed but have my doubts ... way too many doubts). With all the paradigms - agile and etc. , gazilion of frameworks in all the different languages, the complete avoidance of database l…
:) We do have a lot of new cool database technologies. They may be the right choice in some specific domains. I still think RDBMs are the best generic choice. And good RDBMs design skills a core developer competence.
Re: Design Your Own Database (2004) [pdf]
#6Does anyone still do this(database design)? (sarcasm here with a bad taste ebcause I might be wrong in my belief ... and I want to be right that the articla info is used by everyone(or at least the majority) in the software development filed but have my doubts ... way too many doubts). With all the paradigms - agile and etc. , gazilion of frameworks in all the different languages, the complete avoidance of database l…
:) We do have a lot of new cool database technologies. They may be the right choice in some specific domains. I still think RDBMs are the best generic choice. And good RDBMs design skills a core developer competence.
Having done it for a while now I always think that database design is simple. Yet looking at he work of others, many people get it really badly wrong.
Re: Design Your Own Database (2004) [pdf]
#7Does anyone still do this(database design)? (sarcasm here with a bad taste ebcause I might be wrong in my belief ... and I want to be right that the articla info is used by everyone(or at least the majority) in the software development filed but have my doubts ... way too many doubts). With all the paradigms - agile and etc. , gazilion of frameworks in all the different languages, the complete avoidance of database l…
A number of places use Kimball's methodology to design their databases around fact and dimension tables. In those cases, you throw out the rules of normalization.
Re: Design Your Own Database (2004) [pdf]
#8[deleted]
Re: Design Your Own Database (2004) [pdf]
#9Does anyone still do this(database design)? (sarcasm here with a bad taste ebcause I might be wrong in my belief ... and I want to be right that the articla info is used by everyone(or at least the majority) in the software development filed but have my doubts ... way too many doubts). With all the paradigms - agile and etc. , gazilion of frameworks in all the different languages, the complete avoidance of database l…
"Best practice" is losing to "I needed it yesterday." Technical architects need to get better at not buckling to business pressures and business folks need to read this document or stop trying to influence/dictate technical decisions. IMO Developers and business users alike are chasing the perception of success rather than constant critique/improvement which is why so much of this stuff is hiding behind the scenes.