This is about me and my quest for, er... greater things in life? Good food, good drinks, friends and family and my eternal quest to figure out what I want to do when I grow up. (hint: it's probably going to involve code)

Thursday, December 4, 2008

Hey, I like SQL!

SQL is one of my weak spots. I've known that for a while, since college actually. I never thought I'd need it, you know? Ha, add that to the list of things that seemed superfluous to me at the time! SQL? That's what DBAs are for, no? Math? That's what mathematicians are for, no? Parallel programming? I'm never going to work on more than one CPU at a time! Statistics? I'll just look up formulas online. Ah, being young...

Well my use of SQL has increased linearly since I got out of college and I always managed to learn just enough to get by. However, it has caught up with me. I work in a manufacture that creates pumps and valves for the oil fields. Tractability is important and we keep track of everything that is done to our parts during the manufacturing process. Add to that the HR system and our accounting software and we have massive amounts of data in the database. That data is there, just waiting to be used.

Not being great with databases in general is a flaw since I do not know how to use SQL as a tool. Here are a ton of nails, but I don't have a hammer, just a C# screwdriver (I do VB.Net, so I what I really have is a plastic screwdriver!)

Software developers and DBAs have been at war since they ever met. DBAs complain that software developers are nosy and don't know how to use a database properly and exist only to circumvent the systems they have put in place to safeguard against both data problems and intruders. Programmers, on the other hand, complain that DBAs take too long to take care of their requests and are just creating job security for themselves.

On top of that, software developers in general just don't like databases. It seems alien to us. We can't debug it, it gathers data all at the same time and we can't ever be sure that we even got the right data to begin with! Why not just grab everything, loop over it and grab what we need? After all, our data is never complex.

So we attempted to build object databases, which are far from being mainstream at the moment. We like them because we know Objects. But SQL just isn't going away. So we created ORM frameworks to help get rid of the repetitive CRUD operations in our models so we don't have to ever deal with SQL. Then, we declared a holy war on stored procedures, the only thing that can still possibly resist ORMs.

Stored procedures are not faster than code! They're just there so that the DBAs have something to do. There is nothing a stored procedure can do that code can't do!

To all of this I say: Bullshit! Programmers react to SQL the same way VB ASP.Net programmers react to functional languages. They don't want to touch them with a 10 foot pole simply because they don't understand them. All their arguments are a facade to hide the fact that they don't want to learn the new languages.

You don't think the same way when you program in Javascript or Lisp or Ruby versus VB.Net. In the same manner, using SQL forces you to think in SQL, an entirely different beast altogether.

I've really come around recently concerning SQL. I used to be like what I described above, but the more comfortable I became with the language, the more I started understanding it. I realized it is a tool in it's own right, used to solve a wide range of problems and that trying to resolve everything with my favorite language was not always the right thing to do.

If you deal with data and databases, learn SQL. Learn your database management system. There is really nothing else out there that can work this efficiently with relational data. Sure, use ORMs, since they are a tool that helps you keep a clean model. But do not be afraid to use SQL. Do not let the ORM do all the SQL thinking for you the same way you wouldn't let the politicians in Washington tell you what to think! ORMs can't do everything, after all. Sometimes, you just need the data without an associated object.

0 comments: