Neven wrote: > b) Because the DB Server enforces the rules you have to have the UI > guiding the user otherwise its a 'chuck at the db and see > what happens' > UI (ughh). if you do this then you have duplication in business logic > (in the ui and the db) and therefore the inevitability of errors
What about foreign keys and unique indices? Or database constraints? To push your statement to its logical conclusion, such things could all be checked at the UI stage and they could be left out of the db entirely. Personally, I think it's perfectly reasonable to have stored procedures (and triggers) do similar checks on data validity to ensure that no code slips ever permit crap into the database, which it seems to me was what Kurt was advocating. So you might end up duplicating some logic at the front and back ends, but not to cause errors - to catch them. Just like foreign key, unique index and other constraints, stored procedures to do referential checks on data validity are a safety net. Where does referential integrity end and business logic begin anyway? Cheers, Carl _______________________________________________ Delphi mailing list [email protected] http://ns3.123.co.nz/mailman/listinfo/delphi
