The Solution is actually very simple. If you dont like SQL dont use it. If you dont want to use SQL / dont dislike it. You will very soon find out how easy it really is comparing to other Database Sotware. Try adding the same effort into learning SQL as Complaining about it. It sometimes helps.

Tutorial 1
– Making the First Letter of a Word Uppercase.
- Hold in shift and press the letter. ( Dont make it difficult by turning Caps Lock on , Press the letter and turn caps lock off )

Everything is Simpler if you know how to use it.

Das ist aber in keiner Weise ein Gegenargument gegen meine Argumente. Mein Beispiel von Fortran als moderne Sprache war in dieser Hinsicht vielleicht etwas ungeschickt. Es ging mir dabei nur um ein Beispiel für eine Sprache, die zumindest grundlegende Mechanismen der Modularisierung unterstützt.

SQL ist eine relationale Sprache und ist im Umgang mit Mengen imperativen Sprachen immer überlegen. Sie ist mit logischen Sprachen verwandt wie RegEx oder Prolog, aber mit imperativen wie Fortran. SQL ist regulären Mengen und regulären Ausdrücken daher verwandter als Imperativen und Prozeduren, gleich ob SQL prozedurale Programmierung ähnlich RegEx auf eine Art unterstützt.

Ich empfehle dringend ein Studium Datenstrukturen und Mathematik (Mengenlehre, Relationen, Abbildungen). Dann leuchten einem die Vorteile ein. Es hat Gründe, warum man AIs, Graphen oder Netzwerke mit Hilfe solcher Sprachen programmiert.

SELECT
COUNT(*) AS Pipeline_Count
, SUM(CASE WHEN OP.Rating_BidderRate > 3 THEN 1 ELSE 0 END) AS PipelineProbableWinCount
, SUM(OP.EstimateAward_Value) AS Pipeline_TotalValue
, SUM(CASE WHEN OP.Rating_BidderRate > 3 THEN OP.EstimateAward_Value ELSE 0 END) AS Pipeline_ProbableWinTotalValue
, SUM(CASE WHEN O.Recompete = 1 AND OP.Rating_BidderRate >= 7 THEN OP.EstimateAward_Value ELSE 0 END) AS Pipeline_RecompeteIncumbentTotalValue
, SUM(CASE WHEN O.Recompete = 0 AND OP.Rating_BidderRate > 3 THEN OP.EstimateAward_Value ELSE 0 END) AS Pipeline_NewTotalValue
, SUM(CASE WHEN O.Recompete = 1 AND OP.Rating_BidderRate BETWEEN 4 AND 6 THEN OP.EstimateAward_Value ELSE 0 END) AS Pipeline_RecompeteNonIncumbentTotalValue
, C.Id AS CompanyId
FROM
dbo.OpportunityPipeline OP WITH (NOLOCK)

Well PL-SQL isn’t that much better then SQL when it comes to the design of the language. You do get modularization but you loose the set base declaritive way of thinking and working which is a strength of SQL

And I agree with your last two paragraphs. While hibernate is great for many things, it sucks extremely at large volume processing. And SQL shows it powers. Yet this doesn’t make it a nice language.

(Almost) no modularization: Don’t use plain SQL. You should generate it. It’s fairly esay, for example in PL-SQL. That what I do all the time. But you are true, we need more modularity.

No decent development environment appart from the target environment : True I know what you can have when you develop java, and at least, all SQL environment i know sucks. (didn’t try Visual studio…)

Why does a curious developer with over 10 years of experience in database development know some reasons why SQL sucks, but can’t answer the simple question, why these reasons apply?

Pleople don’t know, don’t like SQL. SQL is old fashioned. But they forget, when you do do some serious data manipulation, not only on 100K line, but on 10 000K line (we have 30 000K to 300 000K line in our table and have to compute sum, aggregate etc on it).

In SQL it is just a few minutes hours. And a few line of code. Do it with hibernate and java : hundred, thousand line of code, chance you have Out of Memory Exceptions and it will be far far slower.

Of course if you rely heavily on inheritance in an class based OO language you might easily end up in the same kind of mess one is stuck in with SQL.