4 ms·

the point is though, it's a little bit like a broken calculator. "The Relational Model" represents a logical model as a kind of pure piece of mathematics, and p

the point is though, it's a little bit like a broken calculator. "The Relational Model" represents a logical model as a kind of pure piece of mathematics, and presents a system that isn't just dump disk persistence but actually a logic induction engine. However, this is not how SQL is used in practice. It is possible to implement the relational model in SQL, however if you assume SQL databases are supposed to be implementations of it in and of themselves, they violate the commutative, associative and distributive laws of the relational algebra- it's a bit like a calculator that sometimes gives you 2+2=5 (because it's faster to give wrong results sometimes). In addition, the ergonomics of a typical SQL database system do not make mathematical/logical soundness the easiest thing to achieve. Most developers don't know or care about logical induction or mathematical soundness, they just want a place to dump their objects. That said, out of the open source SQL database systems, postgresql actually does try to implement the relational model properly. But I don't have enough direct experience with it to say definitively how well it does. How many millions of dollars hss NULL != NULL cost the world?

paulddraper 8y ago
> what is better?
- ZenPsycho 8y ago
  well, obviously "worse is better". historically, SQL has been "Good enough" and was sponsored by IBM/Oracle that nobody has bothered to try and implement the relational model correctly, except for perhaps postgres (which used to have its own query language before bolting SQL onto its core engine) what I hope people get out of my comments is not about selecting the right system for today- A better thing does not necessarily exist yet-- But at least understand the relational model well enough to see what its utility is. Functional programming and Logic programming are coming back in fashion, and maybe someone here will build the better thing. I don't think "nosql" databases or graph databases are necessarily the better thing. (but they might be for certain usecases). Though I think relational db systems could learn something about developer ergonomics from them. Interfacing with a DB using a fortran inspired query language is archaic. Constructing the queries using string concatenation has been a security nightmare. You could build something waaayyy better off of prolog or mercury, full programming languages with the inductive logic engine at the core of their paradigm, with a database system integrated in, and expose a graphql api for your isomorphic react web app cos that's how we do in 2018. Even microsoft's linq is a massive improvement over using SQL. Language integration, strong typing. These are things we like, right?
  - paulddraper 8y ago
    > well, obviously "worse is better". > A better thing does not necessarily exist yet Ah, of course. > Interfacing with a DB using a fortran inspired query language is archaic. Constructing the queries using string concatenation has been a security nightmare. Perhaps, but this this often for very ubiquitous technologies. See almost every HTML authoring tool. You can write full application servers in Oracle PL/SQL now. [1] And with PostgreSQL's row-level security, you can easily have a GraphQL server with PostGraphile [2]. But those aren't popular solutions. > ou could build something waaayyy better off of prolog or mercury, full programming languages with the inductive logic engine at the core of their paradigm That doesn't really change the equation. You still either have to (1) choose your DBMS's query language to write your application server (like today) or (2) use one language to construct queries in another (like today). I won't argue that a Prolog DBMS wouldn't be nice. I will argue that in terms of the hard parts of a DBMS, it's not going to fundamentally change things. [1] https://docs.oracle.com/cd/B28359_01/appdev.111/b28424/adfns_psp.htm#g2475353 https://docs.oracle.com/cd/B28359_01/appdev.111/b28424/adfns... [2] https://www.graphile.org/postgraphile/ https://www.graphile.org/postgraphile/
    - ZenPsycho 8y ago
      first off, thanks for the links. Secondly, > That doesn't really change the equation. You still either have to (1) choose your DBMS's query language to write your application server (like today) or (2) use one language to construct queries in another (like today). I don't know if you're misunderstanding me, or I'm misunderstanding you. prolog is a query language. The logical programming paradigm is that a program is a "list of facts" and you run the program by "querying" the state of the world. The only piece missing is making the fact storage engine scalable/robust/production ready. Or.. alternatively, there's the Eve[1] project which starts off with prolog to make a hypercard like environment with a built in data storage layer. Its aim is less production ready apps and more developer ergonomics. [1]: ( http://witheve.com http://witheve.com )
      - paulddraper 8y ago
        I don't think I misunderstood. You yearn for the day when a DBMS uses Prolog for its query language. Users of that DBMS have the choice to either (1) query seamlessly because they use prolog for the entire application (2) query by "gluing" Prolog to their application language.
mamcx 8y ago
I agree with all you said, except this one: > they violate the commutative, associative and distributive laws of the relational algebra I follow the idea of relational set, but implementing a relational language (http://tablam.org http://tablam.org, alpha btw) I see why bags surely are better. Is not a mistake rdbms take it. Make everything sets demand more memory and runtime costs. You need to couple a index or pay O(N) for each mutation and get only a few upsides. If exist a way around this, truly I wanna know. However, exist another reason for what sets are wrong (as being default) them fail to cover the most simple and yet more powerful capability of the relational model: Model data. Is posible to argue than [a, 1; b, 1] must be a set and order not mater. But [a, 1] & [b, 1] are both relations, right? also are [a, b] & [1, 1]. Is wrong to make [1, 1] to [1] just to get a math purity.[1, 1] is valid. Say that duplicates are wrong is non-sense. Also say that "order not matter" is non-sense too. Ironically, the solution for this? add another column just to keep thins as set.

paulddraper 8y ago

> what is better?

ZenPsycho 8y ago
well, obviously "worse is better". historically, SQL has been "Good enough" and was sponsored by IBM/Oracle that nobody has bothered to try and implement the relational model correctly, except for perhaps postgres (which used to have its own query language before bolting SQL onto its core engine) what I hope people get out of my comments is not about selecting the right system for today- A better thing does not necessarily exist yet-- But at least understand the relational model well enough to see what its utility is. Functional programming and Logic programming are coming back in fashion, and maybe someone here will build the better thing. I don't think "nosql" databases or graph databases are necessarily the better thing. (but they might be for certain usecases). Though I think relational db systems could learn something about developer ergonomics from them. Interfacing with a DB using a fortran inspired query language is archaic. Constructing the queries using string concatenation has been a security nightmare. You could build something waaayyy better off of prolog or mercury, full programming languages with the inductive logic engine at the core of their paradigm, with a database system integrated in, and expose a graphql api for your isomorphic react web app cos that's how we do in 2018. Even microsoft's linq is a massive improvement over using SQL. Language integration, strong typing. These are things we like, right?
- paulddraper 8y ago
  > well, obviously "worse is better". > A better thing does not necessarily exist yet Ah, of course. > Interfacing with a DB using a fortran inspired query language is archaic. Constructing the queries using string concatenation has been a security nightmare. Perhaps, but this this often for very ubiquitous technologies. See almost every HTML authoring tool. You can write full application servers in Oracle PL/SQL now. [1] And with PostgreSQL's row-level security, you can easily have a GraphQL server with PostGraphile [2]. But those aren't popular solutions. > ou could build something waaayyy better off of prolog or mercury, full programming languages with the inductive logic engine at the core of their paradigm That doesn't really change the equation. You still either have to (1) choose your DBMS's query language to write your application server (like today) or (2) use one language to construct queries in another (like today). I won't argue that a Prolog DBMS wouldn't be nice. I will argue that in terms of the hard parts of a DBMS, it's not going to fundamentally change things. [1] https://docs.oracle.com/cd/B28359_01/appdev.111/b28424/adfns_psp.htm#g2475353 https://docs.oracle.com/cd/B28359_01/appdev.111/b28424/adfns... [2] https://www.graphile.org/postgraphile/ https://www.graphile.org/postgraphile/
  - ZenPsycho 8y ago
    first off, thanks for the links. Secondly, > That doesn't really change the equation. You still either have to (1) choose your DBMS's query language to write your application server (like today) or (2) use one language to construct queries in another (like today). I don't know if you're misunderstanding me, or I'm misunderstanding you. prolog is a query language. The logical programming paradigm is that a program is a "list of facts" and you run the program by "querying" the state of the world. The only piece missing is making the fact storage engine scalable/robust/production ready. Or.. alternatively, there's the Eve[1] project which starts off with prolog to make a hypercard like environment with a built in data storage layer. Its aim is less production ready apps and more developer ergonomics. [1]: ( http://witheve.com http://witheve.com )
    - paulddraper 8y ago
      I don't think I misunderstood. You yearn for the day when a DBMS uses Prolog for its query language. Users of that DBMS have the choice to either (1) query seamlessly because they use prolog for the entire application (2) query by "gluing" Prolog to their application language.

mamcx 8y ago

I agree with all you said, except this one: > they violate the commutative, associative and distributive laws of the relational algebra I follow the idea of relational set, but implementing a relational language (http://tablam.org http://tablam.org, alpha btw) I see why bags surely are better. Is not a mistake rdbms take it. Make everything sets demand more memory and runtime costs. You need to couple a index or pay O(N) for each mutation and get only a few upsides. If exist a way around this, truly I wanna know. However, exist another reason for what sets are wrong (as being default) them fail to cover the most simple and yet more powerful capability of the relational model: Model data. Is posible to argue than [a, 1; b, 1] must be a set and order not mater. But [a, 1] & [b, 1] are both relations, right? also are [a, b] & [1, 1]. Is wrong to make [1, 1] to [1] just to get a math purity.[1, 1] is valid. Say that duplicates are wrong is non-sense. Also say that "order not matter" is non-sense too. Ironically, the solution for this? add another column just to keep thins as set.