Tuesday, March 24, 2009

Why Object-Oriented languages rock?

I loved coming back from using T-SQL to C# or Java like I loved the view from the picture (view from the l'Esterel's mountains towards Cannes). Of course, SQL-like languages are very powerful and when you do some complicated computations that need many requests to the underlying relational database, this choice may be the right one. At least, as far as the performance is concerned.

If we leave performance concerns behind we still have the language itself. So, what did I miss in this language? I was thinking of enumerating things that I didn't like but after some thinking I conclude that I just missed object-orientation in general.

But what it means? Let's see... I was not able to use any design pattern (e.g. Factory, Strategy or Decorator) and I needed them very badly! Instead of using design patterns I had to add many ugly ifs.

Another thing I missed was abstraction i.e. I wasn't able to create abstract stored procedure and then implement specialized subprocedures. In T-SQL everything you can do is to add some more ifs :) This language is strongly data-oriented which is maybe good but it's not sufficient IMHO.

Yes - it's very vague but it doesn't make sense to compare stored procedures with OO constructs. T-SQL is just yet another language I've learnt and used after many years of writing Java/C++ code and I just wanted to express my feelings.

I don't know what are perspectives for such SQL languages like T-SQL or PL/SQL but I think they should evolve in an object-oriented way. It would be much easier to write stored procedures/classes in e.g. Java, test them and then deploy on the server. This would be a win-win situation. We would gain performance by having stored code invoked directly on the SQL server while we will still be able to use OO constructs and profit from unit tests, design patterns, etc.

Maybe there already are such languages but I just don't know them (most of them are procedural languages) - if you know some let me know.


Anonymous said...

SQL means Structured Query Language, it should neither have ifs or fors because this language is meant to gather data, process them and then pass this result to a real programming language when something else needs to be done.

But some company never seems to have understand that and I have seen tons of business rules written in SQL that should have been written somewhere else.

Przemysław Bielicki said...

You've got an excellent point. But I didn't really mean SQL language but the language for stored procedures i.e. writing business logic on top of the underlying data.

As you pointed out (I totally agree with you) this language is meant to gather data. That would be fine but if DB providers allow developers to put business logic directly on DB servers the languages they provide should be better - that was my point.

Just to be clear - I'm generally big anti-fan of stored procedures but anyway I'm open enough to see their usage in some particular cases.


Anonymous said...

@first anonymous commenter
I'm very glad that databases have a language of sorts, like T-SQL, that allows me to perform some manipulations before retrieving the code. All kinds of complex gathering, sorting and filtering are very inefficient if you first have to retrieve all the data for that.

Of course, premature optimization is the root of all evil. We have written applications that serve thousands of clients a day, that do not use any stored procedures (or any caching for what that matters). However, saying that an RDBMS should not provide 'ifs' and 'fors' is just ignorant.

Anonymous said...

I agree. (I feel the same frustration when building web pages and trying to code presentation logic via nested tags -- no matter how rich in features the tag library may be. Fortunately, some newer web frameworks let you code your presentation logic in plain old Java. I just wish they were part of the standard tool set.)

I wonder whether Oracle's subset of Java retained the object-oriented capability.

Anonymous said...

I can't say I've ever been writing Transact-Sql or PL/SQL and felt the need to use the Decorator pattern or anything else really OO. My feeling has always been that OO and databases don't mix. The relational model is, I think, too sophisticated to ever being manipulated in an OO way. Look at Microsoft Linq (language-integrated query), for example. It's not OO so much as it is functional and generic, and these are two paradigms that are completely independent of OO. In fact, generics were basically a rebellion against OO.
Of course, I have worked on projects where we claimed to use OO and we also had a database, but there was always a great deal of awkwardness at the seams, and this is one reason I've never really embraced the concept of OO.