Generally, you wouldn't want to do it that way. Most enterprise-level relational database software supports what are called 'trigger' functions. These are just little bits of code that you build into the database itself and which get fired when something specific happens, such as a row of data getting added to the database or an existing row getting updated. You can use these trigger functions to do almost anything, but a typical usage would be to carry out some sort of sanity checking on the data being presented. By doing this job in the trigger function code, you end up with a more 'future proof' database, since it doesn't matter where the data is being presented to you from - it could be from a web-based app, from a command line prompt or from some DB management tool, it would all get validated in the same way. This keeps your data integrity rules where they belong, i.e. in the database itself and also means you don't have to re-code the validation every time you want to add a new interface between the data and the front end application.