I think it just depends on where you come from!

I started “database” programming (developing applications that use databases) using DBase and Clipper (does anybody remember?), and I remember spending hours and hours developing routines to handle data, that can be solved in few minutes using SQL.

I’m not going back there.

May be there is something else to come, better, but from my point of view SQL is heaven!

Seems interesting to browse through different views on SQL and its user. SQL & PL/SQL make Data access and manipulation more interesting and easier.

With exposure to both Development and Administration of Oracle Database, I can’t picture how tough it would have been if there wouldn’t have been SQL, PL/SQL.

Thanks & Regards,
Zaffer Khan

I’m sorry if I come off as condescending. It’s not my intention. It’s just that SQL is so universal, used by so many people. And few think of the possibilities, or problems, that arise outside their own particular usage scenarios.

As someone who has worked in databases both large _and_ small, and as both a database _and_ an app developer, I was merely trying to bring a different viewpoint to the conversation. I can say with some confidence that I have a wider view of the merits and blemishes of SQL than some others do. Though not as wide as many others, such as probably our hosts here at <a href="http://TechTarget.com" title="http://TechTarget. " target="_blank">TechTarget.com</a>.

To answer your question though, one looks with such criticism at a microscopic level when it becomes necessary to do so in order to _get things done_.

Things are not always so simple, whether we like them to be or not, when dealing with large amounts of data, or strict processing time limits. I am at the _small end_ of the “large dataset” category, dealing with 10-year-history tables holding several million records. Small inefficiencies when dealing with this many rows can amount to _hours_ of difference in batch processing times. At a conference last spring, I encountered someone who was importing hundreds of millions of new records on a _nightly_ basis, pushing Oracle to its very limits.

“Simple” and “large” are very relative terms. You are fortunate if you are able to keep your SQL simple without having to worry over performance. But we should all recognize that not everyone is in the same situation. Everyone has a different set of obstacles, and everyone deserves to get the help they need in overcoming them. It does no one any good to dismiss others’ obstacles as unnecessary or unimportant. Regardless of whether that person is a veteran or a newbie.

SQL is a tremendous achivement. Its fast and simple. What else do you need ? There are no “leaks” and its not slow. If it is slow then perhaps it isnt SQL that is the problem, but the database design. Databases should be designed so that the queries used against it are fast and easy. Proper DB design along with SQL is the answer. People should not make things so difficult or tedious. Databases should not be made to be so difficult. all they do is hold records, period. I mean really, what does one really need to do ? Add a record. Delete a record. Edit a record (update) and find matches to a criteria. Thats it. And it should not be made anymore difficult than that. I often wonder if some programmers, trying to save a millesecond on a query, would spend an additional hour or two making a SQL statement so complex that they cant’t read it themselves the next day. Maybe 2 queries need to be performed instead of one, saving an hour of coding time and maybe taking a second or two more to execute. Easier is far better than complex. I keep it simple. I got a second to spare.
Time to go fishing!

Of course “select a.tablefield, b.tablefield,c.tablefield from address a, branch b, costcentre c where a.idn= b.idn and c.idn = b.idn and a.cat=’ACCESS’” is always going to be harder to read if you you a lax on providing an effective way to read SQL.

It is really a matter of which method you take “quick and dirty” or “structured” with a view to someone else reading your code.

SQL supports both, but you have to choose which you are going to do.

I’m very happy not having to learn another development language for my work which is almost entirely about database integration.

I don’t have to write code, just scripts and then have the external application execute the script. For that SQL suits me fine.

Especially after you have been away from the application for a few months.

I concede that the advantages are not as great if you are dealing with a poorly designed application, which is just a redesign of a punched card system with the SQL doing nothing more than replace READ/WRITE statements.