4 ms·

there's a reason why not everything in SQL is a set and it's that you can do a lot of mathematical work from inside the engines. this was largely overlooked in

there's a reason why not everything in SQL is a set and it's that you can do a lot of mathematical work from inside the engines. this was largely overlooked in the article and undefined what operations between set of multiple cardinality would require and if this would result back to what they call unwieldy runtime errors when doing math over set of mismatched cardinality.

setr 7y ago
>there's a reason why not everything in SQL is a set and it's that you can do a lot of mathematical work from inside the engines I don’t see the relationship between those two things; or rather, what the latter even means. Can you expand? Also, apparently the “sets” described in the article are actually multisets aka bags [0] — so the same semantics as any other RDBMS/SQL. No idea why they’d confound the two, especially when set vs bag semantics is a well-discussed topic in the literature.. [0] https://edgedb.com/docs/edgeql/overview/#everything-is-a-set https://edgedb.com/docs/edgeql/overview/#everything-is-a-set
- LoSboccacc 7y ago
  something like this SELECT StudentID, Name, (SELECT COUNT(x) FROM StudentExam WHERE StudentExam.StudentID = Student.StudentID) / (SELECT COUNT(x) FROM StudentEnrollmetnPeriods WHERE StudentEnrollmetnPeriods.StudentID = Student.StudentID) AS ExamsTakenPerYear FROM Student ORDER BY ExamsTaken DESC; works because the result from aggregate are scalar and thus math operations always meaningful, albeit this in particular might not be the most brilliant example, there's definitely a case for running such operations on the server, because you might filter on the results, say, like "select all student with less than 2 exam per year average" at which point either you have the distinction between scalar and set in the language itself and you can filter invalid queries at the parsing level or you have to do the checks at runtime when two set are in an operation with mixed cardinality, halt the query and throw an error. edit: count(x) because I don't know how to escape asteriks
  - HelloNurse 7y ago
    Set and scalar should be regarded as data types in a more traditional programming language, and treating a 1-element set as a scalar is a type coercion that works as much as other type coercions: only if the data matches expectations.
    - LoSboccacc 7y ago
      you're missing the point: it's not about coercion or data types per se, it's whether the error happens at parsing or runtime; of course the software has ways to figure out intention but is it something we actually want? it's not coincidence that the article complains about the same thing but in reverse: > This is legal, but only if the subquery returns not more than one row. Otherwise, an error would be raised at run time. except the 'fix' reintroduce it in a way that's subtler and way hard to detect because now everything is a set even when the intent is to have a scalar.

setr 7y ago

>there's a reason why not everything in SQL is a set and it's that you can do a lot of mathematical work from inside the engines I don’t see the relationship between those two things; or rather, what the latter even means. Can you expand? Also, apparently the “sets” described in the article are actually multisets aka bags [0] — so the same semantics as any other RDBMS/SQL. No idea why they’d confound the two, especially when set vs bag semantics is a well-discussed topic in the literature.. [0] https://edgedb.com/docs/edgeql/overview/#everything-is-a-set https://edgedb.com/docs/edgeql/overview/#everything-is-a-set

LoSboccacc 7y ago
something like this SELECT StudentID, Name, (SELECT COUNT(x) FROM StudentExam WHERE StudentExam.StudentID = Student.StudentID) / (SELECT COUNT(x) FROM StudentEnrollmetnPeriods WHERE StudentEnrollmetnPeriods.StudentID = Student.StudentID) AS ExamsTakenPerYear FROM Student ORDER BY ExamsTaken DESC; works because the result from aggregate are scalar and thus math operations always meaningful, albeit this in particular might not be the most brilliant example, there's definitely a case for running such operations on the server, because you might filter on the results, say, like "select all student with less than 2 exam per year average" at which point either you have the distinction between scalar and set in the language itself and you can filter invalid queries at the parsing level or you have to do the checks at runtime when two set are in an operation with mixed cardinality, halt the query and throw an error. edit: count(x) because I don't know how to escape asteriks
- HelloNurse 7y ago
  Set and scalar should be regarded as data types in a more traditional programming language, and treating a 1-element set as a scalar is a type coercion that works as much as other type coercions: only if the data matches expectations.
  - LoSboccacc 7y ago
    you're missing the point: it's not about coercion or data types per se, it's whether the error happens at parsing or runtime; of course the software has ways to figure out intention but is it something we actually want? it's not coincidence that the article complains about the same thing but in reverse: > This is legal, but only if the subquery returns not more than one row. Otherwise, an error would be raised at run time. except the 'fix' reintroduce it in a way that's subtler and way hard to detect because now everything is a set even when the intent is to have a scalar.