| > Is this the norm? I'd say no if you were to treat your data with the same requirements as accountancy systems, like double entry bookkeeping accountancy systems. So accountancy systems and thus your app would let you make changes to data that forces the reason for change to be documented, but either way its documented using the app, so that when looking back, just like accountants and auditors know why a change has occurred when doing year end or quarterly reports, you can also do the same. It also helps you highlight devs not cutting the mustard and it also highlights any potential fraud occurring inside the business with staff gaming the system. I'd never allow any direct change to the db, but then my apps would also be encrypting data making it near impossible to perform changes to a db, other than messing around with the unencrypted data in index fields, which forces hackers to acquire the app and reverse engineer it, and then they have to understand the obfuscation built into the apps besides the obfuscation built into the db, but this approach makes rebuilding corrupted db indexes easier should they ever occur. I know some people prefer having all the logic in the backend, but its about balancing the logic between the backend and the front end, ie spreading risk to make hackers jobs harder. > This also seems like it could bring compliance issues. This approach (making and documenting changes from within the app(s)) would meet all compliance and ISO standards. |