5 ms·
Most ORMs will not do the level of aggregations you want or need without writing raw SQL within your ORM. If you are already writing raw SQL in your ORM for agg
by phereford 10y ago
Most ORMs will not do the level of aggregations you want or need without writing raw SQL within your ORM. If you are already writing raw SQL in your ORM for aggregation level computations, you might as well create a stored procedure, make it IMMUTABLE (if you can) and gain those performance benefits.
At the end of the day, I would just use the tool that has the most comfortability with the team on the project. You can obviously start with an ORM, but there may come a point in time where performance needs a little boost.
- azernik 10y agoWhat are the real performance benefits of stored procedures over sending the hand-written queries over the wire through your ORM? I suspect small to none, and at the cost of having code that lives in the database rather than in version-controlled code.
- gaius 10y agocode that lives in the database rather than in version-controlled code If you think you can't version control stored procs, then you are doing something badly, badly wrong. What's the difference between a "script" which is a text file on a filesystem at the end of the day, versus a "stored proc" which is a block of text in a database, loaded off a file in a filesystem?
- jstanley 10y agoThe "script" gets deployed simply and reliably using your existing tooling, and stays in sync with the surrounding code.
- tokenizerrr 10y agoReplace the stored procedure from version control at deploy time.
- azernik 10y agoAnd then you have to make sure your deploys are atomic so that the app code and stored procedures don't get out of sync on failed deploys... Or your stored procedures now become one more thing that has to be backwards compatible, in addition to your DB schema... I've run into all of these problems with stored procedures, and they SUCK. Good deployment tooling can solve them, but it's a lot of effort for questionable reward.
- kofejnik 10y agothis absolutely mirrors my experience
- gaius 10y agoa lot of effort for questionable reward It's a small amount of effort for a thousand-fold increase in performance and not having to re-implement the same functionality in every app and in every language that connects to that DB. YMMV.
- icebraining 10y agoThe argument was between using SQL in stored procedures or SQL in queries sent by the application, so you don't have to re-implement anything (just share the SQL queries between apps), and I very much doubt you'll get a thousand-fold increase in performance.
- spdionis 10y agoThousand-fold increase in performance by shaving off network and query compilation time?
- phereford 10y agoHonestly, it's yak shaving at that point. Like the article pointed out, you can create an index on a stored procedure that is IMMUTABLE. That will have some effect on the performance of the query. There are other patterns you can use to track via version control the changes for your stored procedure.
- grzm 10y agoOne performance benefit of stored procedures in Postgres is that you can perform a multi-statement transaction in the stored procedure, saving the network overhead of multiple round-trips between the application and the database. This may not be a common occurrence for many applications, but it is a legitimate performance benefit when the need arises.
- anarazel 10y agoNote that the network protocol allows pipelining for multiple statements (including transaction control ones), too. Unfortunately only few client libraries (e.g. pgjdbc) make use of that :(
- azernik 10y agoI don't know about Rails and ActiveRecord, but I can do this in Slick.
- kofejnik 10y agoyou can do multi-statement and nested transactions even in Rails
- mst 10y agoIf you're already version controlling your schema, the CREATE OR REPLACE FUNCTION call lives in whatever's version controlling your schema. If you're not already version controlling your schema, you should seriously consider starting whether you're using sprocs or not.
- feld 10y agoYou can literally do version control in the database as well. Upgrade and downgrade your entire scheme at will. Unfortunately the only open source software I'm aware of that does this is Archiveopteryx http://archiveopteryx.org/db/mailstore http://archiveopteryx.org/db/mailstore http://archiveopteryx.org/db/schema http://archiveopteryx.org/db/schema