Thank you for the comments. Andl already has regular expressions and compound datatypes. They do everything you list here. [Regex is pretty obvious, and user types are as per TTM.]
Namespaces: interesting idea. I'm not sure a hierarchical model is the best choice, but I can definitely see that 'packages' of data and code could be useful. Andl has the concept of a catalog, to store persistent information about relations (tables), operators and types (they have to go together). The catalog name would make a natural namespace. Definitely one for the todo list. Regards David M Bennett FACS Andl - A New Database Language - andl.org -----Original Message----- From: sqlite-users-boun...@mailinglists.sqlite.org [mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of James K. Lowden Sent: Wednesday, 17 June 2015 4:45 AM To: sqlite-users at mailinglists.sqlite.org Subject: Re: [sqlite] Mozilla wiki 'avoid SQLite' 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 _______________________________________________ sqlite-users mailing list sqlite-users at mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
