Quick Start: Git for personal use
SVN client over SSH to remote Unix server from Windows
Quick Start Grinder - Part V
Quick Start Grinder - Part IV
Quick Start Grinder - Part III
« Scalability myth
» Easy geodata utilities
The previous reference to respecting SQL got me thinking a little more, specifically about why SQL is unfashionable among programmers now. Comparing to Java and eXtreme Programming as the fashionable tools, the main reasons cited where:
I think there is some truth to this. However, none of these are valid, in my humble opinion.
“SQL is not object oriented”. Frankly, I don’t see what is the problem here. Modern databases like Oracle 8+ support objects (rather, user defined types) as columns. However, dbms may never support polymorphism (because of the C in ACID). My argument is that SQL is designed to do quick interaction with data. Since data is a necessity for most programming, why not use what is best for dealing with data?
“SQL is not portable”. If one use ANSI-SQL, it is indeed quite portable. However, the moment you have more than about 10 tables in the database, you will end up using special SQL features provided by the vendor. This, naturally makes it less portable. My argument is that, in an enterprise, a dbms is a significant investment. Even if you want to, it is a very hard exercise to move to another engine. Considering that, how often are you going to need to migrate your applications? One way to get around this is to have a dbms specific file in your code where all SQL queries used are stored. For a new dbms engine, you just need to create another file with translated queries.
“It can’t be refactored easily; or doesn’t nicely support YAGNI”. This, I think is the biggest hurdle. It takes significant thought upfront to design a database. You will need to think about things you are going to need, even though you are not going to code in the first 10 iterations and design the database accordingly. Altering tables and relations is not at all a good practice, when there is data in those. Personally, I favour adding a new table with a relation, rather than adding columns to an existing table. Compare this with the world of OOP. It is quite easy to change data members in a class, if proper accessor functions are used. Though similar operations are possible in dbms, it is not very easy.
That said, things will be much better if there are better object databases with easy query languages like SQL. I use ZODB a lot and it is fantastic. I have heard great things about Intersystems Caché. For the time being, there are object-relational mappers like Hibernate and Oracle TopLink.
Links to ponder:
“Customer is the King, data is the General and programmer better not be the jester starting civil war.”
http://martinfowler.com/articles/evodb.html
Covers the topic at some length.