3 ms·
Have we learned nothing in the last 10 years? Aside from the siren song of better performance, there are few other reasons to model your domain in the database.
by picardo 11y ago
Have we learned nothing in the last 10 years? Aside from the siren song of better performance, there are few other reasons to model your domain in the database.
Throwing business logic into stored procedures wily-nilly is a terrible idea for a lot of reasons. First, there is no standard method for testing stored procedures functions; you have to put a lot more effort into devising a test strategy for your database functions than your controller functions. In addition, you've now coupled the business logic with the database, and you cannot move your data around easily. And, lastly, if you have a large database, adding new functions and triggers will involve some downtime, too.
To sum up, don't replace your Rails app with a database unless you really know what you're doing.
- ams6110 11y agoMost SQL databases that support stored procedures have some kind of unit testing framework available these days, in fact have had for many years. Possibly as a third-party product or project, but the tools exist. If you design your stored procedures right, they can be an abstraction over your data model. You then can change the data model without the stored procedure interface necessarily having to change (though in most cases, changes to the data model are usually done to support new requirements, which typically involve new or changing business logic as well).
- picardo 11y agoThat's good to know. The question then becomes whether it makes sense to support yet another testing framework. The pros of performance gains have to outweigh the cons of additional complexity by a considerable margin to make database functions a viable choice over application level functions.