in reply to Getting started with databases
Learning databases is no trivial matter, despite what you may hear around.
There are three basic steps:
There are several ways to learn database theory well. The best way is to attend a university course or a good course of comparable quality.
I see some hands rising, with predictable objections. "University courses are boring and full of negligible details that I would never need in real life."
Not so. Even if you perceive the course as abstract and unrelated to real life experience, database theory is one of the subjects that can have strict applicability to real cases. The problem is that it isn't easy to see the theory usefulness when examining small cases.
If you get acquainted with relational theory, and especially if you become used to apply relational concepts to real cases, then you'll see that you can understand the problems and find a solution.
Another method of learning database theory is through a good textbook. It depends on your attitude towards learning. There are people who can't grasp a concept from a book and need a good teacher in front of them, and there are people who can get the most complicated ideas from a book only.
Either way, here are a few titles that I can recommend:
|Elmasri, Navathe||Fundamentals of Database Systems||Addison Wesley||0321204484|
|Atzeni, Ceri, Paraboschi, Torlone||Database Systems: Concepts, Languages, Architectures||McGraw-Hill||0077095006|
As an alternative, there are several articles online. Check this address: http://www.palslib.com/Fundamentals/Fundamentals.html.
I don't mean to discourage you. What you need to know to get yourself started is not that much. It would be enough to grasp the basic relational concepts of data separation, relations between entities, operations on data sets, and transactions.
The other important concepts ( referential integrity and normalization) are really needed only if you are designing your own database.
Once you understand enough database theory to know what you need to do with your data, then you must learn some Structured Query Language to communicate with your database.
There are several ANSI standards, but not all the database engine are fully compliant to the most recent ones. You can assume that if a DBMS claims that its SQL is ANSI-92 or ANSI-99 compliant they are worth a try.
Be careful of specific implementations from a database. Advanced features such as triggers, constraints, cursors, and stored procedures may differ substantially between different engines. Don't get dependent on a given features without checking that other engines support it as well.
Finally, once you are confident that you can talk to a database and can get what you want, it's time to work on the programming interface.
For Perl, this means mostly learning the DBI. The original book is a bit outdated, but it is still a great source, which you can integrate with the current documentation. Our Tutorials can give you a good start, but only if you know the basics first.
A last piece of advice that maybe is the most important one. Whatever you decide to do, don't use any feature blindly, just because you've seen someone using it or because someone said it is "the right way." Try to understand WHY it's used, and only then add the feature to your bag of tricks.
_ _ _ _ (_|| | |(_|>< _|