3 ms·
SQL always seemed to me to be the way it is in order to lend itself to optimisation at the database end. It is easy to look at any SQL query (that doesn't use s
by rlpb 16y ago
SQL always seemed to me to be the way it is in order to lend itself to optimisation at the database end. It is easy to look at any SQL query (that doesn't use subselects) and see how the DB engine can efficiently execute it by walking down the appropriate indexes.
Try doing that with an ORM or a key/value store.
- jbarciauskas 16y agoCan you elaborate the issues an ORM has in dealing with indexes? An ORM can be made aware of indexes via, e.g., annotations or other declarative syntax, and prefer those when joining and filtering, and will probably be more consistent about it than a human developer.
- rlpb 16y agoI didn't mean that ORMs have problems with indexes; just with efficiency: because you can tell the SQL engine what you want done instead of having to bring the data to the code (in particular when iteration can be folded into the query).
- jbarciauskas 16y agoYes; but even this only goes so far. Execution plans change based on statistics collected by the query optimizer. SQL was invented because query optimizers do a better job than humans. The same is commonly true for ORMs.