Is it bad software design to have JDBC/raw SQL and also use an ORM?  I don't mind using an ORM for boilerplate CRUD, but some queries are better in SQL (for me).  I'm not arguing for or against ORMs.  I've read about them until I'm blue in the face.I used JDBC in my question, but it could have been DBI, or some other database interface.  ORM can be any of them.How about maintainability?  Would mixing the strategies complicate it?  To me the maintainability of an application efficiently becomes even more blurrier, if it is a compiled language vs. a scripting language.  I have to recompile Java.  I don't have to recompile Python or PHP.If my SQL is in a model layer, does that change anything?EDIT:  If I use find a point where I need to use SQL in my ORM, in my model, what kind of data is sent back?  I won't be able to use something like person.save('somevalue'), for example, will I?
Is it bad software design to mix JDBC SQL calls and use an ORM in an application?
design;sql;orm
It depends on your application needs. For example, I've been working for banking, and when you have to generate thousands of invoice payments orders, it's better to have an stored procedure to do the task (it'll be by far faster) and to update the model tables directly in the database.Then you can show the results with ORM, even update a payment order (but not thousands).If your application is not performance critical, it's better for programming mantainability to deal with ORM, so that you don't need to know about the underlaying DB technology.So that one more time, it depends on your needs and if you keep the code organized and clean (apply a DAO pattern for it, for example), it's not a bad architecture nor unmaintainable code.