Function relations
Quote from johnwcowan on March 30, 2020, 11:21 pmYou might want to look at SQLish to get some ideas, even though it's not quite what you want. The idea there is to provide something with the full power of the RM that still looks something like SQL.
My aim is to provide the power and stay well away from anything that looks like SQL.
SQL syntax is pretty challenging, once you get past simple selection and the odd join. Correlated sub-queries and anti-join spring to mind. The cognoscenti will bitch about how you've mangled their language, and the rest will find it just as confusing as SQL.
If you look at an API like LINQ in C# or Java streams you see how simple the core idea can be. You don't need arcane syntax.
[BTW if you are going to put forward an idea of this kind, I think you need something better than Google Docs. That URL is horrible.]
Quote from Dave Voorhis on March 31, 2020, 6:25 pmNot quoting anything because this is kind of a general comment following from the preceding ones, rather than a specific reply.
There are two distinct and equally reasonable applications of the relational model. One is to build DBMSs, for which Codd's Rules and TTM pre-/pro-scriptions should apply, and the other is to build query systems that aren't DBMSs. It's reasonable to create useful implementations of the relational model that -- for sensible, pragmatic, predictable and logical reasons -- don't follow Codd's Rules and/or aren't a D.
All I'm saying is it's ***you*** who will have to find a way to cope with ***every possible way*** the data inside the spreadsheet/csv/... can be made non-relational by the users managing that portion of the system. Nulls, lack of column names, domain/type constraint violations all over the place, lack of declared keys and correspondingly ensuing duplicate rows, you name it they will give it. And convince the users afterwards that your way of coping is reasonable.
If a relational system has a low-level language, that low level cannot be used to subvert or bypass the integrity rules and constraints expressed in the higher level relational language.
It's pretty clear to me that CTRL+S in whatever dinky toy tool will itself invoke elements of a "low-level" language that will indeed facilitate to "bypass and subvert integrity rules and constraints expressed in the higher level language".
Quote from Erwin on April 1, 2020, 9:00 amQuote from Dave Voorhis on March 31, 2020, 6:25 pmNot quoting anything because this is kind of a general comment following from the preceding ones, rather than a specific reply.
There are two distinct and equally reasonable applications of the relational model. One is to build DBMSs, for which Codd's Rules and TTM pre-/pro-scriptions should apply, and the other is to build query systems that aren't DBMSs. It's reasonable to create useful implementations of the relational model that -- for sensible, pragmatic, predictable and logical reasons -- don't follow Codd's Rules and/or aren't a D.
All I'm saying is it's ***you*** who will have to find a way to cope with ***every possible way*** the data inside the spreadsheet/csv/... can be made non-relational by the users managing that portion of the system. Nulls, lack of column names, domain/type constraint violations all over the place, lack of declared keys and correspondingly ensuing duplicate rows, you name it they will give it. And convince the users afterwards that your way of coping is reasonable.
Of course. But that's par for the course if someone is giving you a spreadsheet/CSV/whatever. In some businesses, a gaggle of spreadsheets is their information system, and anything that helps organise it even a little bit is a step in the right direction even if it's still miles away from the desired destination.