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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.