undefined | Better HN

0 pointscivilized3y ago0 comments

But a view also does that? Like, if you want to assemble information about a user from several different tables, you can have a view that does the join for you.

0 comments

jrumbut3y ago

Sure, but people never use those. Also it gets back to the discoverability issue. The ORM documents relationships with the rest of the model code, if you have a poorly named view in a large, complex schema it may be hard to find. You could reinvent the wheel easily.

Like everything with SQL, you can solve the problem but sometimes the solution isn't elegant. People want elegance.

Justsignedup3y ago

This is an accurate description of how I think of this problem. And it would be tough to describe all this:

- table a joins b yay a view

- table b joins c yay a view

- table c join d yay a view

- table a joins to d. well technically it can, but are you really gonna write all the permutations of views for every possible join?

ORMs encode that nicely so I can easily walk the relationships and get to the query I need.

dragonwriter3y ago

Essentially all of the actual information is encoded in the foreign key constraints (in combination with uniqueness constraints.) What ORMs provide that SQL doesn’t isn’t much encoding of information (they usually have facilities to distinguish data tables from pure join tables, and to distinguish 1:1 and 1:M, (M>0) relations from 1:(0-1) and 1:M, (M>=0) ones, so they do encode some additional information), but provide convenient syntactic shorthands for the client to use the encoded relationships.

This would be easy to add to SQL, as syntax sugar, https://news.ycombinator.com/item?id=34587412

Justsignedup3y ago

To be completely honest, I forgot who was it, but about a year or 2 ago someone posted about a sql alternative language. The goal was to be adaptable to be used in all sql application, but a better designed language so that things like a calculation in a select can be reused in another select column, and better structure to make things easily reusable or composable, etc.

Just a new language to replace sql, that is still sql but just better designed with the benefit of 30+ years of language design improvements.

2 more replies

bambax3y ago

> Sure, but people never use those

Why not? I use views all the time, and they seem pretty elegant and simple to me.

j / k navigate · click thread line to collapse

0 comments

jrumbut3y ago

Like everything with SQL, you can solve the problem but sometimes the solution isn't elegant. People want elegance.

Justsignedup3y ago

This is an accurate description of how I think of this problem. And it would be tough to describe all this:

- table a joins b yay a view

- table b joins c yay a view

- table c join d yay a view

- table a joins to d. well technically it can, but are you really gonna write all the permutations of views for every possible join?

ORMs encode that nicely so I can easily walk the relationships and get to the query I need.

dragonwriter3y ago

This would be easy to add to SQL, as syntax sugar, https://news.ycombinator.com/item?id=34587412

Justsignedup3y ago

Just a new language to replace sql, that is still sql but just better designed with the benefit of 30+ years of language design improvements.

2 more replies

bambax3y ago

> Sure, but people never use those

Why not? I use views all the time, and they seem pretty elegant and simple to me.

j / k navigate · click thread line to collapse