Easily maintain SQL triggers is a nice example of the kind of thing that you can do with SQL on the '400 these days.

'Smart' databases might seem like an unalloyed good thing, but I'm not so sure anymore. Do you really want your business rules mixed up with your database?

Sure, triggers mean that you can't break the rules even when editing data with SQL, DFU, or the wonderful WRKDBF, but the temptation would be to put too much intelligence into the trigger.

You want your business rules to live in your business objects. These are the things it which you code all your business rules - usually in the form of OO classes, but you can use an RPG service program or suchlike to take the same role. Your triggers should be thin wrappers, simply calling out to the business objects for verification of the required data change, and for any consequential database operations. The database should be just a repository for your data.

Of course, your front end (be it a GUI, a web service, or whatever) should also be as thin as possible, and hook into your business objects.

And thus a 3-tier architecture is born!