For basic things, using SQL to check for consistency is acceptable I suppose. But how would you use SQL to verify a phone number was properly formatted based upon whether or not it was international? How about a valid zip code depending on the country? How about a reservation, making sure it doesn't fall within the date and time range of another reservation for the same room? Given these examples, I don't think it can be said that all validations should happen in SQL, and if I am doing SOME in the application, my own feeling is that I may as well do them all and be sure all is well before the insert/update happens. Also, all doing the updates myself gives me control over which validations to apply to my data, and I have a validation system where I can turn things on and off for each field/column. I would have to modify the schema to do the same thing in SQL, even if I could do all validating there.
Bob On Feb 23, 2012, at 6:35 PM, Pete wrote: > Yes, some people do rely on a db's data checks to flag errors, and wise > people they are. That's where data checks belong, not in your application > code. Why duplicate the work the db already does for you? It probably > does it more efficiently and most of the time it's easier to define. _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
