On Tue, 16 Jun 2015 09:56:38 +1000
<david at andl.org> wrote:
> The question is: what should a database language do? Andl can already
> match or surpass SQL on database programming tasks, but is that
> interesting enough?
>
> What would make a database programming better, or best?
Two things I've often pointed to are namespaces and regular
expressions. Another is compound datatypes.
SQL and C both suffer from a single variable namespace. We get around
it by using prefixes, e.g., "local_memcpy" or "annualized_returns".
C++ added namespaces to the language. I suggest SQL's successor do the
same, but use the Unix filesystem's hierarchical namespace as a model.
Putatively,
ATTACH DATABASE 'foo.db' as /db/local/foo;
CHANGE DATABASE /db/local/foo;
CREATE TABLE annualized/returns ....;
As far as I can tell, all the basic file and link management features
of the filesystem have analogous utility in a database. (I would extend
that idea to permission bits, about which we could have a robust
discussion if you're interested.)
Regular expressions likewise belong in a query language. The LIKE
operator, an NIH relic of SQL's IBM origins, belongs on the ash heap of
history. Best to follow Russ Cox's advice and restrict the regex
syntax to constructs with O(n) complexity.
Finally, compound datatypes would simplify and encourage the use of
natural keys. Something along these lines,
CREATE UDT stock_key ( asof datetime, cusip char(8) );
CREATE TABLE prices( stock_key, price float );
CREATE TABLE returns( days int, return float, stock_key
references prices );
Constraints defined on the compound user-defined type would of course
apply to whatever table it appears in.
I thought I'd pass these along because you asked and because I don't
remember seeing them in TTM.
I assume you're supporting row-generators. Do you intend to support
table-comparison, too? What about insert/update as assignment?
--jkl
