4 ms·
Great point, we'll add that. I don't think we do joins that much better than SQL does. We're thinking whether there's potential there, maybe through understand
by maximilianroos 4y ago
Great point, we'll add that.
I don't think we do joins that much better than SQL does. We're thinking whether there's potential there, maybe through understanding foreign keys — but we're being conservative about introducing change without value.
- maximilianroos 4y agoAdded: https://github.com/prql/prql/pull/697 https://github.com/prql/prql/pull/697
- igorkraw 4y agoI looked at the book after this and have to say, I'd heavily recommend spending the next dew months just improving joins (and complex joins especially). Like GP says, relational modelling is the interesting bit about SQL and I don't feel exaggerative in saying the only reason I use SQL are joins, and so the only reason I'd introduce the complexity of your project into my stack would be if it makes handling joins, views and other aspects of relational modeling and slicing nicer - one example could be many to many relationships, or the gradient between graph/document based and normalised table based modeling
- switchbak 4y agoI second this. However, it's important that we don't make it so easy that we hide the cost of the join itself.
- Sankozi 4y agoThe biggest failure of SQL joins is not using declared foreign keys. For example it should be something like "JOIN USING fk_invoice_customer c" instead of repeating each time the relationship between invoice and customer entries already defined in foreign key
- neamar 4y agoMost engines support NATURAL JOIN, which isn't perfect and has drawbacks, but allows for shorter joins.
- deleted 4y ago[deleted]
- riezebos 4y agoI always found it surprising that joining on foreign key is not possible in SQL. I'm no expert, but looking at PRQL this feels like it should fit in quite well with the philosophy.