> You are encouraged not to implement all the business logic in the web application (i.e. your script), instead do it in the database schema using views, triggers or rules. If the system evolves, new ports will be intended to open to the database, and you have to re-implement the logic in each separate database client. Over and above, triggers can be used to transparently and automatically handle fields, which often provides insight when debugging problems with your application or tracing back transactions.
This is exactly the other way around. SQL code is difficult to debug, it lacks common programming language features and is more cumbersome to write and to deploy. You definitely should not implement your business logic in a Query Language, regardless of how Structured it is.
Designing Databases
The first step is always to create the database, unless you want to use one from a third party. When a database is created, it is assigned to an owner, who executed the creation statement. Usually, only the owner (or a superuser) can do anything with the objects in that database, and in order to allow other users to use it, privileges must be granted.
Applications should never connect to the database as its owner or a superuser, because these users can execute any query at will, for example, modifying the schema (e.g. dropping tables) or deleting its entire content.
You may create different database users for every aspect of your application with very limited rights to database objects. The most required privileges should be granted only, and avoid that the same user can interact with the database in different use cases. This means that if intruders gain access to your database using your applications credentials, they can only effect as many changes as your application can.
add a note
User Contributed Notes 2 notes
o at olgierd dot me ¶
1 year ago
Anonymous ¶
4 years ago
"You are encouraged not to implement all the business logic in the web application (i.e. your script), instead do it in the database schema using views, triggers or rules. If the system evolves, new ports will be intended to open to the database, and you have to re-implement the logic in each separate database client."
This doesn't make sense to me. I might be misreading it, but I can't see how this adds to security. It sounds like implementing business logic in the database just increases the amount of work you have to do if you ever want to upgrade or change your SQL database.
