News: 1618482309

Maybe it's just me, or it's a bad example, but the sample shown looks far quicker and easier to understand as SQL than Logica?

It's not just you.

I could be interested in seeing how a query with several outer joins would be represented, but not interested enough in googling it.

I'd also like to be the first to XKCD this board: https://xkcd.com/927/

I would like to see a more complex example, also - and see how it really becomes more readable and "structured" than SQL.

Also, why the "=="? Niklaus Wirth was right, you need to change the assignment operator, not the equality one.

And the ":-" ?

I don't know why they decided to use the "penis" operator. Is not gender neutral.

My sentiment exactly, unbelievably insensitive towards e.g. penilewise challenged trans males and probably many other minorities yet to be discovered!!1!

:- is from Prolog. All of these languages descend from Prolog via Datalog I think (Datalog is pretty much Prolog without the Turing-completeness, or with less Turing-completeness, so queries are guaranteed to terminate).

I'm not sure why this is more interesting than Datalog though.

Oh it's better than that, it's much better than that.

They use '==' both for assignment and equality, depending on context.

So, you know, it's like people writing maths where you often lazily say 'f(x) = x^2' to mean 'I am defining the function f(x) to be x^2' and then 'sin(t) = t' to mean 'I am interested in the values of t for which sin(t) is equal to t' rather than 'I am defining sin(t) to be 0 for all t' (the answer to that one is 't=0' of course, which is again not defining t as 0'). Very occasionally people are more explicit but usually not.

Except for some fucked-up reason of their own they've chosen to use '==' for both things instead of being compatible with several hundred years of lazy mathematicians and using '=' .

This language is ... not going anywhere, is it?

Yep it's a poor trivial example. Having written/maintained several SQL based reporting systems over the years, often querying unverified data, SQL can get very messy & very quickly as you add complexity. Much of my work was to manipulate the data at the right point in the process to simplify the process, validate the data and end up with optimised queries that ran at acceptable speeds.

So Logica might be a good thing if it significantly reduces the work necessary to do the above but is impossible to tell from this article.

On the other hand, one of SQL's big advantages is that a non-coder can build their own simple (and not so simple sometimes) queries to help them do their job and something like Logica could maybe exclude those users if the SQL interface was walled off.

But I presume Google are looking at this from a perspective of multiple magnitudes of complexity higher than anything I've ever done and I can see that at that level it makes sense to use code that is much more powerful and maintainable (if that actually is the case with Logica).

Worse than that. What happens when you 'join' multiple bits together - you'll have no way of understanding the efficiency of the final SQL.

Can you do that anyway without looking at the query plan?

Do bookies take bets on when Google will abandon yet another project? Asking for a friend.

I can't picture Google doing that, maybe I'll look in Picassa

This thing is explicitly a research project. For which mean 'they've already abandoned it'.

Bring back [1]QUEL , that's what I say!!

[1] https://en.wikipedia.org/wiki/QUEL_query_languages

Is Logica a typo? Caligo (latin) is an actual description ... it's a messy mess.

Yes, returning to the fundamentals of relational calcula would have great advantages, especially as a "wire" protocol betweent the client language and the server.

My first thought was 'how long will this last. I'm not knocking it as I primarily write in SQL and have seen, written long bits of code**, I just want others to give their views on how realistic this is and could it take off.

Basically, is it worth learning?

**Projects often dictate how fast you have to go and this leads to very messy quick fixes just to get a result (thats my defense and I'm sticking to if(haha))

"Is this a flash in the pan"

No, more like a "floater"

Now I can't code my way out of a wet paper bag but I did learn SQL.

For some reason it just made sense. I think it was the "English" style of expression that helped me overcome my mental block on anything resembling maths or logic. The same with Cobol which I also had to learn. As others here have said the example looks to me like the SQL version is more comprehensible. The Logica one has more of a feel of a high level programming language so my mental block comes into play and it all looks very confusing. I would hate to have to work through a more complicated example.

Still having said all that I am not in the target audience for this so others may find it easier to use.

It looks awful in that example, but I'd like to see a more complex example.

It might be better.

very messy quick fixes

So you're the one!

Pass.

A complex SQL stored proc (SP) can be nice and readable, using lots of other SPs or functions.

This fits with the idea of "small, understandable, reusable pieces of logic that can be tested, given names"

And obviously the use of parameters / named variables.

However there's nothing to stop someone writing a 1000+ line monster SP

Unless logica in some magic way stops that, readability will still depend on the authors coding style

But we're not talking about stored procs here, we're talking about database queries. No stored proc in the world is going to address the readability of a query which is several hundred lines long and designed for speed.

If it's several hundred lines long it needs to be designed for speed.

A stored proc is a query....

Performance advantage & code reuse as main advantages (plus having code under source control f you go that route on your SPs)

I normally use them heavily, though I did nearly go insane when doing something really easy on Postgres because I didnt realise it allowed SP overloading so you could have lots of SPs with the same name but different arguments so as you were developing and modifying the DB and associated code weird things would happen even though I could swear the code was right. It wasn't until I found out the SQL to list all the SPs that I laughed long and loud and scared the whole office.

Although for me anything ORACLE should normally be avoided, the one thing I DID like about ORACLE SQL was the fact you could have a single package with multiple methods, functions, some public others private. Easier to keep things all together. SQL server the same thing could have 10's of seperate SQL stored procs and functions. Makes to code base a bit more messy.

And yes, once you get over a hundred lines it can become a paid to read. Not really designed to do lots of complicated stuff easilly.

having 16 joins or more in a SQL is a Pain.....

having people design tables without knowing what they are doinf and they having to deal with the consquences afterwards is also a real pain. Not everyone has the option of refactoring a database (OR part of it) to make it more meaningful.

Experience as a sometime DBA stongly suggests that a major source of poor RDBMS performance is that the system designers have no idea of which queries will be the most frequently used and that this information is seldom available to the DBA. This isn't really their fault since very often the system's sponsors and future users don't know this either. The result is that all too often a well-designed RDBMS schema generates a database that runs like a lobotomised snail.

Very often its performance can be hugely improved by merely adding indexes that actually support the queries that the application's logic needs to do its designed task and.or reorder the columns within indexes so the queries return rows in the required sequence without needing to sort then as they are extracted from the database.

Its quite remarkable how much a star schema can be sped up by merely reordering columns in the prime indexes and, of course, this sort of fix doesn't require any of the SQL queries or the code calling them to be rewritten.

Whats needed to improve the average RDBMS performance or maintainability is not a sexy new way of writing queries: instead all that's needed is an SQL interface with an EXPLAIN capability to analyse how any given query will interact with the RDBMS content, structure and query mix plus a DBA who is well enough trained to use the EXPLAIN output to better match the database's physical structure to the queries executed against it.

I've always used SPs for web access - you can normally secure a DB so the web user can only run SPs and not random queries - initially a a security step but it quickly became apparent you could actually write really complicated code by breaking it down into well chosen SPs and objects and end up with libraries of SPs and functions that made life really easy for yourself and isolate the DB structure from the user (or web user) and make quite major changes without fucking up the web interface or the three hundred random copies of excel about the office.

I do wonder whether Logica is another one of these inventions by someone who hasn't read the SQL manual to the end.

They seem to be missing the real reason SQL becomes a problem in large systems - which is that it's usually embedded in a general purpose programming language as strings that can't be analysed and refactored.

The solution is something like jOOQ, which provides an API that has type safety, compile time checking and the possibility of refactoring. I'm sure similar solutions exist for other general purpose programming languages.

Being in strings shouldn't prevent that, more a tooling problem. Not sure if I'm recalling correctly as I don't like the language, but didn't vb.net support inline xml that was treated pretty much as code rather than a string?

Thats what ODBC helps with and JDBC fixes almost entirely, because both generally return columns in the programming language's nearest match to a particular column's data type.

Of course, if the database was "designed" by the sort of numpty who thinks integer values should be stored as character strings, then all you can do is light the blue touch paper and run.

I'm not familiar with ODBC, but JDBC does not solve the "queries as opaque strings" problem, nor does it offer type safety. Something like jOOQ generates mappings by querying the schema, so you go from JDBC like:

ResultSet rs = statement.executeQuery("SELECT foo, bar FROM baz");

while (rs.next()) {

...

}

To jOOQ like:

List things = context.select(BAZ.FOO, BAZ.BAR).from(BAZ).fetch(mapper);

Both the query and mapper work in a type safe, compile time checked, manner. If the underlying DB schema changes, it's caught at compile time.

It may be the case that:

Good programming is about creating small, understandable, reusable pieces of logic

But you don't (shouldn't) write entire programs in SQL. You can talk about operations on a relational database in terms of algebra (which has some implicit notion of procedure and order) or in terms of calculus (where you define the transformation rather than individual steps). Most people would find it easier to conceive of what is going on in procedural terms and SQL is an expression of that form (firstly JOIN this to that then secondly SELECT a subset WHERE come condition applies) but in practical databases the query optimiser may well reorder the operations to get the best performance so SQL is in reality only an expression of the desired outcome.

Again, in a practical system, you might need to chain some small number of operations together in a transaction to achieve some specific purpose and you might create a stored procedure for convenience, but if it isn't small, understandable and reusable you're doing it wrong.

In any case, given that SQL is just a specific syntax for expressing the basic maths, I'm not sure that simply inventing a new syntax to express the same concepts is going to help the cause of understanding especially if you have users determined to "learn by experience, rather than reading". I can see nothing about:

MagicComment(comment_text:) :-

`comments`(user_id:, comment_text:),

user_id == 5;

with its magic punctuation that is inherently clearer than (note that the CAPS-lock is typically optional):

select comment_text from comments where user_id = 5

[Edit: sorry, it looks like this has all been said already - phone call intervened before "submit"]

Yes, but FWIW SQL is Turing complete.

This just seems to be a 4GL a la the Eighties.

Also, do CGI still own the Logica trademark?

Rapport anyone?

the whole point of SQL is that it is easy (quick) to parser and optimise on the server side, relative to the time taken to execute.

For further optimisation, a hash indexed cache of execution-plans and cursor handles avoids most of the actual parsing.

where things can be improved is in the area of mapping (to classes), and client side syntax checking.. where C# LINQ has basically got it nailed

from c in database.Customers where c.Id == 5 select c;

=>

select c.* from customers where c.Id = 5;

For repetitive queries, where the parameters are passed separately, parsing time is not relevant.

SQL wasn't developed for the server but as the client interface for non-programmers. It was then more or less deliberately knobbled by vendors who wanted to be able to push their own proprietary solutions.

SQL is a nightmare to parse!

Large numbers of keywords to support.

Inconsistent grammar (sometimes "var = x " sometimes "(var1, var2) (x, y)"

Massively recursive you can place another "select" almost anywhere.

Really inconsistent as in you cannot place another "select" just anywhere.

It can also be tedious to write matching lists of variables to lists of parameters or values is just plain error prone.

Codd hated SQL! It took the beautiful mathematically provable relational algebra and turned it into a messy natural language with all its ambiguities and opportunities for misunderstanding.

Here are a few examples of SQL parsers:

https://github.com/antlr/grammars-v4/tree/master/sql

Most of these come in at 2000 plus line of ANTLR code compared with a language like smalltalk with comes in at 104 lines of code.

Maybe someday someone will invent views to encapsulate complicated query logic. Or am I dreaming?

Any programming language that requires backticks is doomed because they can be a real problem for non-ASCII keyboards and users.

Backticks are used in .MD files (markdown documentation) and Javascript.

17 punctuation characters in the simplest of queries, 9 of which require the use of the shift key.

File alongside the hundred previous attempts to create a "better" query language that have all been worse than SQL.

I suspect that [1]CGI , which bought the venerable UK software outfit [2]Logica in 2012, may still have a vague desire to hang onto its trademark.

[1] https://en.wikipedia.org/wiki/CGI_Inc.

[2] https://en.wikipedia.org/wiki/Logica

Yes, this was what I thought. Did they do any research before thinking of the name, like, I don't know, typing 'logica' into some search engine or other (perhaps they don't have access to a search engine, I don't know)?

Wake me when it runs on MSSQL, PostgreSQL, and even SQLLite

A research project with no manual, a few examples only some of which appear to be better expressed in Logica than SQL is not entirely enticing.

SQL can be a real pain to write at times, but I'm not immediately seeing this as the solution.