On 9/15/11, Always Learning <centos@xxxxxxxxxxx> 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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
