2 ms·

I completely agree with every word you said. But why do you want columns that contain tables recursively? Aggregate and non-aggregate mixture is supported in

by ora600 16y ago

I completely agree with every word you said. But why do you want columns that contain tables recursively? Aggregate and non-aggregate mixture is supported in the standard and Oracle with the analytical expressions (if I got your meaning correctly).

lmz 16y ago
Why not columns that contain tables? It would certainly make things easier. e.g. Get a list of customers with their orders: SELECT ... FROM customers LEFT JOIN orders ...; To get this into a presentable table, I would have to keep track of the previous customer's ID and only start a new row if the current customer ID is not equal to the previous customer ID. If table-valued columns were available, each customer row would have a column containing a table of their orders.
- ora600 16y ago
  I have a problem with designing a data model with the "ease of displaying it in a pretty way" as the main consideration. Nested tables may well be the bee's knees, but probably not for this reason alone...
jerf 16y ago
"But why do you want columns that contain tables recursively?" This is the sort of question you ask because you've become so used to the way SQL does things that you can't even think outside the box. (No offense; this is SQL's fault, not yours.) If I recall correctly, the Relational Model fully permits this. And once you start thinking about it, you can see that there are numerous places where you're basically trying to do things like this, and it would be much easier if you could have tables in rows, but instead you have to put a series of weird hacks in. Anytime you have a table that participates in multiple many-to-many relationships, it would be a lot cleaner if SQL could just say "Look, this ID has no meaning except inasmuch as it identifies another set of rows somewhere else, so how about we just cut to the chase and say that those rows are just here?" The joins could be the default and magic access to the ID could be the thing you have to type extra to get. "Aggregate and non-aggregate mixture is supported in the standard and Oracle with the analytical expressions (if I got your meaning correctly)." What I mean was more a syntactic issue than a question of whether it's possible; there's very poor separation between the two, so combining them is even harder. (And crap, the design for my combinator-based language is starting to coalesce in my head. Damn it, that wasn't supposed to happen, I was being vague on purpose....)

by ora600 16y ago

lmz 16y ago

Why not columns that contain tables? It would certainly make things easier. e.g. Get a list of customers with their orders: SELECT ... FROM customers LEFT JOIN orders ...; To get this into a presentable table, I would have to keep track of the previous customer's ID and only start a new row if the current customer ID is not equal to the previous customer ID. If table-valued columns were available, each customer row would have a column containing a table of their orders.

ora600 16y ago
I have a problem with designing a data model with the "ease of displaying it in a pretty way" as the main consideration. Nested tables may well be the bee's knees, but probably not for this reason alone...

jerf 16y ago

"But why do you want columns that contain tables recursively?" This is the sort of question you ask because you've become so used to the way SQL does things that you can't even think outside the box. (No offense; this is SQL's fault, not yours.) If I recall correctly, the Relational Model fully permits this. And once you start thinking about it, you can see that there are numerous places where you're basically trying to do things like this, and it would be much easier if you could have tables in rows, but instead you have to put a series of weird hacks in. Anytime you have a table that participates in multiple many-to-many relationships, it would be a lot cleaner if SQL could just say "Look, this ID has no meaning except inasmuch as it identifies another set of rows somewhere else, so how about we just cut to the chase and say that those rows are just here?" The joins could be the default and magic access to the ID could be the thing you have to type extra to get. "Aggregate and non-aggregate mixture is supported in the standard and Oracle with the analytical expressions (if I got your meaning correctly)." What I mean was more a syntactic issue than a question of whether it's possible; there's very poor separation between the two, so combining them is even harder. (And crap, the design for my combinator-based language is starting to coalesce in my head. Damn it, that wasn't supposed to happen, I was being vague on purpose....)