What ORMs have taught me: just learn SQL
wozniak.ca
What ORMs have taught me: just learn SQL
1–10 of 25 posts
Re: What ORMs have taught me: just learn SQL
#2(2014)
One case where I still think ORMs like SQLAlchemy make a great sense is in open-source software than can be configured to work with different databases (lime SQLite/Postgres/Maria).
If you own the entire stack and can control what FB the software is used with, fine, but it can be worth trading some performance to flexibility.
Re: What ORMs have taught me: just learn SQL
#3I think if you are using an ORM you should know SQL anyway.
If you are running into trouble with the mappings it means the the database layout isn't how you are using it in your application.
And that is find when you have more than one application using the database, but, if you are the only one using it, then likely you should change it until it does.
In our team we typically use noSql for databases with single applications, and SQL for ones where we have a lot of applications hanging off the same database.
Just because it means we can match what the application is doing and the database closer.
Re: What ORMs have taught me: just learn SQL
#4"In these cases, I’ve elected to write queries using a templating system and describe the tables using the ORM. I get the convenience of an application level description of the table with direct use of SQL. It’s a lot less trouble than anything else I’ve used so far."
This has been the best that I've encountered myself.
Re: What ORMs have taught me: just learn SQL
#5(2014) One case where I still think ORMs like SQLAlchemy make a great sense is in open-source software than can be configured to work with different databases (lime SQLite/Postgres/Maria). If you own the entire stack and can control what FB the software is used with, fine, but it can be worth trading some performance to flexibility.
You know what works really well regardless of database? Regular boring old Ansii SQL without vendor-specific addins.
Re: What ORMs have taught me: just learn SQL
#6A number of specialists in the field of databases got together and designed a DSL specifically for working with databases. It's actually a pretty good fit for its domain and is reasonably well designed. It's also pretty simple (it's even right in the name).
Then a bunch of non-specialists said "we don't want to use more than one language" and came up with some hacks to write DB queries in languages that were never designed for that. The hacky stuff actually ends up generating the proper query language behind the scenes, poorly.
One would wonder why would anyone prefer the hacks, but the appeal of using one language for everything is strong. This is also why DSLs never took off in general despite promising to significantly lower the cognitive load due to being a better fit for the problem domain. At least with most DSLs there are usually additional reasons not to use them: the implementation is usually not as good as the popular languages. This is not true for SQL, and yet is suffers from the same problem.
Re: What ORMs have taught me: just learn SQL
#7(2014) One case where I still think ORMs like SQLAlchemy make a great sense is in open-source software than can be configured to work with different databases (lime SQLite/Postgres/Maria). If you own the entire stack and can control what FB the software is used with, fine, but it can be worth trading some performance to flexibility.
You know what works really well regardless of database? Regular boring old Ansii SQL without vendor-specific addins.
Sure, but you'd still need to connect and interface with the SQL implementations - the queries themselves are the smaller piece of the work if you want to support several different database backends.
Re: What ORMs have taught me: just learn SQL
#8(2014) One case where I still think ORMs like SQLAlchemy make a great sense is in open-source software than can be configured to work with different databases (lime SQLite/Postgres/Maria). If you own the entire stack and can control what FB the software is used with, fine, but it can be worth trading some performance to flexibility.
I think supporting multiple databases is an antipattern for most software (open source or not). Being able to change the database driver does not qualify as support.
If you really do want to support multiple databases, you need to write code with all of them in mind and test with them, not just leave it to users to find all the bugs when they change the DB driver to something no-one else actually uses.
Re: What ORMs have taught me: just learn SQL
#9The ORM vs SQL debate is a false dichotomy, at least if you take Hibernate as an example.
You can use a combination of JPQL, native SQL, and object mapping. There's nothing stopping you from mixing and matching.
You can use an ORM to save entities, and using native SQL to retrieve projections, Spring Data makes this easy, as it will do the mapping, if you provide an interface.
Re: What ORMs have taught me: just learn SQL
#10(2014) One case where I still think ORMs like SQLAlchemy make a great sense is in open-source software than can be configured to work with different databases (lime SQLite/Postgres/Maria). If you own the entire stack and can control what FB the software is used with, fine, but it can be worth trading some performance to flexibility.
I think supporting multiple databases is an antipattern for most software (open source or not). Being able to change the database driver does not qualify as support. If you really do want to support multiple databases, you need to write code with all of them in mind and test with them, not just leave it to users to find all the bugs when they change the DB driver to something no-one else actually uses.
I disagree. If you don't need any database-specific funtionality, are OK with the least-common denominator, why not?
I run a large number of open-source software privately. It would be a way smaller number if I couldn't use them with Postgres.
Many users and projects will start on sqlite but as they mature migrate to clustered instances of a hosted database. It's great that this can be supported without each project implementing every DB.
I have been the user hitting a bug (which I was able to submit a fix for) in the scenario you describe. I much prefer that to not using the software at all or setting up a MySQL instance.