On 9/15/11, Always Learning <centos at u61.u22.net> wrote: >> Next you'll be saying you don't use triggers and constraints either. > > Not consciously. Never heard of them. You should take a look at constraints, they are good for ensuring certain types of data integrity. For example, it would make the database to stop situations like somebody trying to insert a record referring customer #9865 but in fact #9865 doesn't exist, whether it was an unintentional user error or a bug in the application. > Hopefully that is always possible - retrieving EXACTLY what was stored > in the database. Why would one want the database to manipulate (change) > data ? Is that a solution for lazy programming ? No, in many situation, it's a more secure method. Databases can have privileges set. You could have triggers and stored procedures that update certain records that cannot otherwise be altered by the application which can be written by a third party. For example, a stored procedure would require both a debit and credit account for transferring funds and/or checks that the actual amount is present before doing it. Without this, a bugged application or rogue user/dev who run the app with privleged access would be able to transfer funds that don't exist. > Simplicity and good design makes applications fast. For some apps, fast is king. For some, data security and integrity is ultimate. Would you want your banking transactions to run faster by stripping out security and validation checks, at the risk that some dude can transfer all your money into somebody else account? If so, please let me know your bank account details and access credentials, I have a program to speed up your banking transactions... ;) > The integrity of the data can be divided into two aspects: ensuring the > data remains constant (unaltered) while stored, which is the > responsibility of the operation system and the database software, and > the data's integrity from an application perspective. Junk-in always > causes Junk-out even when using 'non-dumb' databases :-) And if the database can further ensure that the application cannot put junk in, whether due to a bug, user error or deliberate fraud, why not? Especially when it's likely to be faster because it's native code.