I still don't understand what problem ORMs solve and I've used many different ORM solutions for over a decade. SQL really is the best and simplest interface to

I still don't understand what problem ORMs solve and I've used many different ORM solutions for over a decade. SQL really is the best and simplest interface to get data out of a relational database. Some people will argue that SQL is too complicated for simple queries like CREATE, READ, UPDATE, DELETE but I would disagree because these simple operations require simple queries. Reading an element by ID is the easiest operation of all: `SELECT * from tablename WHERE id=idnumber`. It's not difficult at all. Abstracting this away inside complex objects doesn't solve any real problems, it just creates more problems. Sometimes developers will argue that they end up reusing variants of the same query in too many places... That is a poor argument; if that's the case, it means that your code is poorly designed. If you organize your code in such a way that components have clear and distinct responsibilities, you're not going to end up with duplicated queries. Also, the perceived 'impedence mismatch' between OOP languages and relational databases is only apparent when you try to design a data layer in OOP code which exposes a general purpose interface to execute specific queries. Impedence mismatch can be solved simply by dealing with each database operation on a case-by-case basis using raw SQL or Language Integrated Queries (E.g. LINQ). It adds a little bit of boilerplate, but it's absolutely worth it. You don't need general purpose entities just to access data.