First off all non-trivial applications have issues with ORM. They are great for CRUD operations but beyond that they just don't work. This isn't a unique problem to your situation. Don't let anyone tell you that you are doing something wrong by running up on the limits of whatever ORM you are using, they all suck at something, most of the times performance and flexibility.

SQL is just source code. Whether it is embedded in your application language, or stored in its own files, it is just source code that needs to be version managed just like any other source code asset.

The idea that separating this logic out and storing it somewhere else (stored procedures) is a panacea, is false, it just moves the problem to somewhere (and probably someone) else, which will cause more synchronization issues in the long run.

All software systems should strive for high cohesion, this means in your case, put the logic closest to where it is used so it is easily found, managed and follows the Principle of Least Astonishment.

Even the act of putting it in its own file that is loaded as a external resource by the application can put an artificial level of indirection that can cause confusion and maintenance hassles.

First off all non-trivial applications have issues with ORM. They are great for CRUD operations but beyond that they just don't work. This isn't a unique problem to your situation. Don't let anyone tell you that you are doing something wrong by running up on the limits of whatever ORM you are using, they all suck at something, most of the times performance and flexibility.

SQL is just source code. Whether it is embedded in your application language, or stored in its own files, it is just source code that needs to be version managed just like any other source code asset.

The idea that separating this logic out and storing it somewhere else (stored procedures) is a panacea, is false, it just moves the problem to somewhere (and probably someone) else, which will cause more synchronization issues in the long run.

All software systems should strive for high cohesion ( sometimes referred to as locality ), this means in your case, put the logic closest to where it is used so it is easily found, managed and follows the Principle of Least Astonishment.

Even the act of putting it in its own file that is loaded as a external resource by the application can put an artificial level of indirection that can cause confusion and maintenance hassles.

First off all non-trivial applications have issues with ORM. They are great for CRUD operations but beyond that they just don't work. This isn't a unique problem to your situation. Don't let anyone tell you that you are doing something wrong by running up on the limits of whatever ORM you are using, they all suck at something, most of the times performance and flexibility.

SQL is just source code. Whether it is embedded in your application language, or stored in its own files, it is just source code that needs to be version managed just like any other source code asset.

The idea that separating this logic out and storing it somewhere else ( stored procedures  ) is a panacea, is false, it just moves the problem to somewhere ( and probably someone ( DBA ) else, which will cause more synchronization issues in the long run.

All software systems should strive for high cohesion, this means in your case, put the logic closest to where it is used so it is easily found, managed and follows the Principal of Least Astonishment.

Even the act of putting it in its own file that is loaded as a external resource by the application can put an artificial level of indirection that can cause confusion and maintenance hassles.

First off all non-trivial applications have issues with ORM. They are great for CRUD operations but beyond that they just don't work. This isn't a unique problem to your situation. Don't let anyone tell you that you are doing something wrong by running up on the limits of whatever ORM you are using, they all suck at something, most of the times performance and flexibility.

SQL is just source code. Whether it is embedded in your application language, or stored in its own files, it is just source code that needs to be version managed just like any other source code asset.

The idea that separating this logic out and storing it somewhere else (stored procedures) is a panacea, is false, it just moves the problem to somewhere (and probably someone) else, which will cause more synchronization issues in the long run.

All software systems should strive for high cohesion, this means in your case, put the logic closest to where it is used so it is easily found, managed and follows the Principle of Least Astonishment.

Even the act of putting it in its own file that is loaded as a external resource by the application can put an artificial level of indirection that can cause confusion and maintenance hassles.