Well here is a summary of it all:
1) Choosing the Wrong Database: If lots of data, choose a better more optimized database.
2) Choosing Too Many Databases: Just develop your programs for one database, don't worry about being compatible for others.
3) Know Your Data: Don't be wrong about the data size, if it is required, etc...
4) It's Just Like Excel, Right?: Databases are more complex then they seem, and should be done by someone with DB understanding.
5) Third Normal Form is Not the Holy Grail: Not everything should be normalized, sometimes it is more efficient not to.
6) What a Great Place to Hide Application Logic!: Database code isn't scrutinized as well as it should be.
7) Who Needs Backups?: (Ok this is too obvious)
8) Yes, You Need Version Control: (Obvious also) If you got people working and changing your database code, it's good to have a version control for backup and updating reasons.
9) Use the Tools: Use the tools and wizards, they make everything cheaper and more efficient in the long run.
10) Don't Assume Everything is a Nail Just Because You Have a Really Big Hammer: Not everything should be in a DB, some things are just very simple and can be put in a local file or XML. It would make everything less complicated.
Those are some good tips to remember.
P.S. The way of "SQL": I always knew there were two ways of saying "SQL".
One: see-quel
-or-
Two: es-que-el
Well I read that if you are basically talking about Oracle and SQL Server then it is pronounce as: see-quel. However, if you are using something like mySQL and DB2 then it is pronounced as es-que-el. Hmmm, an interesting fact.
No comments:
Post a Comment