I share Araq's dislike for SQL, but there is at least one "declarative style"
SQL-like language that I've used that does work extremely well, called "kdb+/q"
or RealSQL, depending on which incarnation you look at.
It is much simpler, and has a few things going for it - such as embracing order
of records (which SQL has a love-hate relationship with, which makes a lot of
things extremely awkward to the point of being unusable) and doing automatic
foreign key chasing, which is so logical and useful that it's word SQL insists
you explicitly join everything.
For example, this ANSI sql query:
select o_year,sum(case when nation = 'BRAZIL' then revenue else 0 end) /
sum(revenue) as mkt_share from (
select extract(year from o_orderdate) as o_year, revenue, n2.n_name as
nation
from t,part,supplier,orders,customer,nation n1,nation n2,region
where p_partkey = l_partkey and s_suppkey = l_suppkey and l_orderkey =
o_orderkey and o_custkey = c_custkey and
c_nationkey = n1.n_nationkey and n1.n_regionkey = r_regionkey and r_name
= 'AMERICA' and
s_nationkey = n2.n_nationkey and p_type = 'STEEL') as all_nations
group by o_year order by o_year;
Run
Becomes (for exactly the same table definition)
select[order.year]revenue avg supplier.nation=`BRAZIL from t where
order.customer.nation.region=`AMERICA, part.type=`STEEL
Run
(This is TPC-H National Market Share Query 8 from the TPC-H benchmark)
Most of the part missing in the second part is simply automatic foreign key
join ("chase") , although there are other things that make the query simpler as
well.
This is implemented and included in a programming language environment derived
from APL (of which earlier versions were called "k" and the newest version is
called "shakti"). The language itself is quite niche and virtually unheard of
outside of finance (and is unpopular with many people), but the query language
is much nicer to use than SQL.
