11–20 of 23 posts
Sorry, it is wrong. SQL is not baſed on ſets, but bags, which are quite different and more complicated. And, by the way, CTEs are a feature of ISO SQL, not only of MS SQL Server. Finally, entity‐relationſhip is not terribly practical as a model, but as diagrammiŋ.
Sorry, it is wrong. SQL is not baſed on ſets, but bags, which are quite different and more complicated. And, by the way, CTEs are a feature of ISO SQL, not only of MS SQL Server. Finally, entity‐relationſhip is not terribly practical as a model, but as diagrammiŋ.
I often wish platforms would expose their internal calculus in a separate syntax, so we wouldn't have to work through the SQL translation layer. Algebraic operators would be nice too.
Sorry, it is wrong. SQL is not baſed on ſets, but bags, which are quite different and more complicated. And, by the way, CTEs are a feature of ISO SQL, not only of MS SQL Server. Finally, entity‐relationſhip is not terribly practical as a model, but as diagrammiŋ.
This is true, SQL does not require everything to be a set, strictly speaking, but internally many platforms append a unique row identifier to bags, so that they can be processed as sets. I often wish platforms would expose their internal calculus in a separate syntax, so we wouldn't have to work through the SQL translation layer. Algebraic operators would be nice too.
In oðer words, internal implementation as ſets do not make SQL ſet‐baſed.
Earlier quoted context omitted.
This is true, SQL does not require everything to be a set, strictly speaking, but internally many platforms append a unique row identifier to bags, so that they can be processed as sets. I often wish platforms would expose their internal calculus in a separate syntax, so we wouldn't have to work through the SQL translation layer. Algebraic operators would be nice too.
Ðat may be true, but what platforms do internally ſhould not affect ðeir flavours of SQL. In oðer words, internal implementation as ſets do not make SQL ſet‐baſed.
Earlier quoted context omitted.
Ðat may be true, but what platforms do internally ſhould not affect ðeir flavours of SQL. In oðer words, internal implementation as ſets do not make SQL ſet‐baſed.
No argument there (ðere?), SQL is an unfortunate language.
Fans of this will probably also like Joe Celko's SQL for Smarties. ISBN: 0123693799 It's unfortunate that a lot of new programmers are relying on their framework's ORM to abstract the SQL away from them, weakening their understanding of it.
I think that's a little unfair to people using ORMs. Obviously I'd hope people don't want to avoid knowledge, but I'll be damned if I want to write SQL, it's not fun for me. That being said I contribute to the ORM of my framework of choice, if I write the solution to my problem once I'll never have to do it again. I think it's a bit like complaining that C programs are trying to abstract away assembly. Yes they are,…
And, what's wrong with SQL? It's simple, powerful, widely known and deployed, and cool(declarative programming, dude!).
I've read a some introductory examples about distinct ORM's and just don't get it. Where's the gain? Apart from database independence(which I don't think it's even desirable in most cases, may be Tom Kyte's books have brainwashed me irremediably), can't see one. How an ORM makes you more productive?
Fans of this will probably also like Joe Celko's SQL for Smarties. ISBN: 0123693799 It's unfortunate that a lot of new programmers are relying on their framework's ORM to abstract the SQL away from them, weakening their understanding of it.
So you want something to wrap your SQL with.
And then, you only have objects in your program, that's why it's called object oriented. So you often need to make objects from the result of your query, and manual bean fill-up is tedious. Therefore, ORMs.
On other hand, DBI is okay, so most Perl project don't use ORMs.
Earlier quoted context omitted.
No argument there (ðere?), SQL is an unfortunate language.
Do you have any thoughts about why there has been no challenge to the SQL syntax? We can easily imagine notations based on relational algebra and relational calculus emerging that could be interpreted at the same levels of an RDBMS as SQL, yet I've not seen anyone attempt it. A good PhD topic for someone?
And the reason why it's stuck is the same story that you can tell over and over about standards.
Earlier quoted context omitted.
No argument there (ðere?), SQL is an unfortunate language.
Do you have any thoughts about why there has been no challenge to the SQL syntax? We can easily imagine notations based on relational algebra and relational calculus emerging that could be interpreted at the same levels of an RDBMS as SQL, yet I've not seen anyone attempt it. A good PhD topic for someone?
Earlier quoted context omitted.
I think that's a little unfair to people using ORMs. Obviously I'd hope people don't want to avoid knowledge, but I'll be damned if I want to write SQL, it's not fun for me. That being said I contribute to the ORM of my framework of choice, if I write the solution to my problem once I'll never have to do it again. I think it's a bit like complaining that C programs are trying to abstract away assembly. Yes they are,…
Personally I don't get ORM's. May be it's because the only I have had to deal with was Hibernate, and seemed to me as an innecesary layer of complexity and bloat, and objects and relations sometimes doesn't map nicely. If you want to persist objects, use an object datastore in the first place, not a relational one. And, what's wrong with SQL? It's simple, powerful, widely known and deployed, and cool(declarative prog…
There are a lot of things wrong with SQL. For example, it's hard to do non-trivial queries because you can't say A = SELECT something FROM foo; SELECT another FROM bar WHERE field IN A. Of course, you can make a view, but views are database structure, and you really really really don't want to change database structure in runtime. So SQL sucks in some places.
In object-oriented programs they have no use of your "tuples". They just can't do anything useful of them, nor give them away (because that would violate code separation). So they have to turn your tuples into some objects (or other objects). Therefore, ORMs.