| Tom Kyte, who for a long time was the "ambassador to the world" for Oracle, makes essentially the same arguments https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUEST... For data that will either : + 'outlive' the user interface - this data will be used forever but we are not sure where e.g. financial docs, records, etc etc + 'extend' past the user interface: this data started on an installed desktop app / green screen but we are not sure how we may want to extend it - eg to an API or to web the DB is the right place to put business logic. Coupling the data with business logic, in the DB, allows almost complete flexibility in how it is access and interacted with at the expense of complete lock in to the DB platform. Which may or may not be a bad thing. But if you have a skilled SQL team and some resources to pay the DB licensing and support piper, this is a good direction to ensure app support longevity. For example, you can do the same thing on desktop or phone or web client or even hardware switches: say you have a DB stored_procedure to indicate that the process of manufacturing this part has reached stage X update_item_status( Item 11111, 'Manufacturing Stage X' ) (these is obviously really contrived but it is an example to make things clear) You can run this, if it is in the DB by: - hitting this button on the assembly line - scanning a barcode can do the same thing - having a user change a status in a UI - have a batch job run off a script with a list of parts to apply the status to And even better, if you want to update how the stored proc works, you update once in the DB and it is available to all 'interfaces' instead of having to update hardware switch code + user screen UI code + batch script code etc etc... I know that an argument can be made that you have an app server layer separate from the DB so this is not a 'real' problem but this approach just puts the app server IN the DB One closing thought: it is often easy to forget that, in most cases, the data is the product of software development and the tooling is just support. Only counterpoints I can think of here are games and interactive demo systems where the process ( of playing the game or using the software ) is the product. Positioning the database and front-end as being similar is a mistake if business goals are thought about from a "the data is the product" perspective. If the rules about how to handle, manage and interpret the data are a core component of that data product, then the argument that the right place for business logic is in the DB is made even stronger. |