3 ms·

Very subjective arguments. Here's the deal: if you design a decent entity manager, you shouldn't have to worry about how the database works. A database was cr

by vkaku 7y ago

Very subjective arguments. Here's the deal: if you design a decent entity manager, you shouldn't have to worry about how the database works. A database was created to ingest and query user data. Programs pretty much ingest and query user data, the amount of regular (non tech) people using SQL is too damn low. So, IMHO, programming the data ingestion and query should be easy, and a good ORM framework should handle it. Of course, to make a programmers life easy, they should start following mindful and clean practices - Otherwise any tool will be a gateway to hell.

JacKTrocinskI 7y ago
So wrong, you always want to know how your database works, you should be tuning your database, and queries against your specific database. Every database has unique technology you can take advantage of and there are performance tuning techniques and design techniques you should be aware of. If you're doing simple INSERT/UPDATE/SELECT then sure, but in a large organization with tons of data that's not gonna cut it.
- vkaku 7y ago
  - SQL is like putting an artificial layer to insert the values you want to insert with some ('') around it. - SQL alone will never help you understand if your underlying table is hashed/unordered, column/indexed or tree/ordered either. - ORMs need not generate SQL statements. An optimized ORM can directly send the data to be inserted in a native protocol to the DB. - The deal is that data tuning / access optimizations have no semblance with SQL or the ORM. - Bad ORM usage / anti patterns does not mean ORMs are bad. It means people use them badly.
  - JacKTrocinskI 7y ago
    - SQL is not an artificial layer, an ORM however is - SQL is a language, it's up to you as a developer to tune your queries against your database (e.g. create and use partitioning, indexes, statistics gathering etc.) - If your using an ORM just to send data via a native protocol then why use the ORM in the first place? - Performance tuning is very closely related to how you write your SQL - This is my opinion but I think almost any usage of an ORM will mostly be bad, no real arguments to support otherwise. Let the database do the work, that's what it's there for.
siempreb 7y ago
> the amount of regular (non tech) people using SQL is too damn low. That is still no reason for me to use an ORM instead. Learn SQL then, that's way more valuable than to learn the next ORM library with all it's issues.

by vkaku 7y ago

JacKTrocinskI 7y ago

So wrong, you always want to know how your database works, you should be tuning your database, and queries against your specific database. Every database has unique technology you can take advantage of and there are performance tuning techniques and design techniques you should be aware of. If you're doing simple INSERT/UPDATE/SELECT then sure, but in a large organization with tons of data that's not gonna cut it.

vkaku 7y ago
- SQL is like putting an artificial layer to insert the values you want to insert with some ('') around it. - SQL alone will never help you understand if your underlying table is hashed/unordered, column/indexed or tree/ordered either. - ORMs need not generate SQL statements. An optimized ORM can directly send the data to be inserted in a native protocol to the DB. - The deal is that data tuning / access optimizations have no semblance with SQL or the ORM. - Bad ORM usage / anti patterns does not mean ORMs are bad. It means people use them badly.
- JacKTrocinskI 7y ago
  - SQL is not an artificial layer, an ORM however is - SQL is a language, it's up to you as a developer to tune your queries against your database (e.g. create and use partitioning, indexes, statistics gathering etc.) - If your using an ORM just to send data via a native protocol then why use the ORM in the first place? - Performance tuning is very closely related to how you write your SQL - This is my opinion but I think almost any usage of an ORM will mostly be bad, no real arguments to support otherwise. Let the database do the work, that's what it's there for.

siempreb 7y ago

> the amount of regular (non tech) people using SQL is too damn low. That is still no reason for me to use an ORM instead. Learn SQL then, that's way more valuable than to learn the next ORM library with all it's issues.