On 9/16/11, Always Learning <centos at u61.u22.net> wrote: > Before anyone can add data for customer 9865, the existing customer > record is displayed on the screen. This helps the user to be sure he/she > has got the correct customer. A customer not found message means the > record does not exist. Consequently it is impossible to add data to a > non-existent customer record. Assuming the system works as expected. Certainly I would expect the application to be at least doing such basic validation and verification. But wouldn't an added layer of safety be better? After all, there could be race conditions where two or more users could cause the application to pass the transaction to the database, which results in more than the allowed amount being transacted because the individual values were valid when the application checked. > In most circumstances, instead of entering anonymous un-meaningful > digits to identify customers, look-ups are done with postal code or > partial address match or partial organisation name match or partial > telephone number match etc. I love easy-to-use user-friendly systems. Which is where AJAX comes in. Typing in a partial address or postal code brings up, almost instantly on LAN environment, matches without having to go to a search page or equivalent. > I use the SQL privileges for tables and enable only the SQL verbs > required by a user. I certainly do not want a user being able to 'drop' > a table. Only I can do that. I wasn't referring to that kind of problems but normal INSERT/UPDATE. > In my systems such actions could not happen. No user gets permissions > they do not genuinely require. If the programme specification says no > 'overdraft' then funds can not be transferred out of an account if that > account balance would go negative. Assuming everything works as expected, no bugs, no intentional hacks and nobody edited the application source without your knowledge ;) I think part of the difference in mentality is the environment our applications run in. I always have to worry about some "admin" in the client's office who thinks they know how to program, and clients wanting to save money, asking them to do some modifications which may lead to problems that I might get blamed for. So having that added layer of checks at the DB level should help... at least hopefully when the other guy gets an sql error, he might look more carefully at what's wrong with his code instead of trying to delete my trigger/constraints :D > Database intervention to validate data is too late, in my opinion. You > do not want junk getting pass the application's data input stage. If you > want an amount of money and someone specifies the currency as GBQ > instead of GBP, then that input error should be identified and rejected > at the data input stage not actually sent to the database to be stored. It's never too late to stop junk from getting stored. Early prevention might be better than late prevention, but any prevention is definitely better than none! :D > That is why I always try to wreck my programmes by entering invalid > data. If I fail to wreck my programmes there is a reasonable certainty > others will fail too. But it doesn't guarantee that somebody/something else can't. After all, we're only humans and I believe all of us have blind spots which can allow edge cases to escape testing.