Database with application logic: includes views, triggers, procedures, etc
Database without application logic: tables/collections only
Personally, even if it can offload development time to the database, having application logic in the database has a lot of issues: difficult to maintain, difficult to version, having the business logic split into multiple parts of the application infrastructure.
When you keep all your application logic in the application code, everything is under control and easier to maintain over time.
Isn't it?
Top comments (3)
I'm a database guy so no-one puts stuff in my tables with me validating it. Firstly all gets should be using views or stored procedures rather than direct table reads, this allows you to modify the database structure without breaking API requests and provide row or even field level security. Puts and posts should come in via a stored procedure and all input should be validated for completeness and referential integrity. The query engine is more likely to optimise query operations than using ORM. Not all business logic can live in the database though (e.g. validate password = PWD confirm). Don't pass data to the database until you have a high degree of confidence it is correct. If you put business logic in your middleware you have to rewrite it when you change stacks. Changing database technology is much rarer.
That's interesting point of view Aaron, thanks for sharing :)
Most of the points you mentioned are true, but, unfortunately most for the developers I saw try to work around those highly secure database architecture just to deliver faster. How can we offer them more agility in such a strict paradigm?
Its mainly about culture and convention. There should be a negotiation about what shape the data needs for front end and then the Business Analyst and data architecht should work out how to store it in the database and resurface it in the correct shape with an API in the middle layer. There are a whole host of other performance optimisations that can take place: Caching of shaped JSON objects to save expensive database calls, Paging requests to limit data set sizes, Graph QL . What I would say is that the front end should NOT be manipulating the shape of the data or running intersects between data sets; that is the responsibility of the middleware or data layer.
Secure database architechture is not a barrier to speedy delivery, it is however a protection against certain types of technical debt.