However, I like the fact that so much logic is in the database--this was part of Philip's original design. He would always say "make the database do the work if you can".
So when the logic is in the DB, I think it's way easier to make sure that duplicate code doesn't end up being written. It has always seemed to me that OpenACS was supposed to be a "thin" layer on top of a rich database schema.
And *huge* reason for that is in case you ever have to do some work with the data outside of OpenACS--say you need to have some other system get at and possibly change your data. It's fairly easy to get an ODBC client or some other software (say a PHP front end, for whatever reason) to connect with the schema, be able to do permissions queries, create new objects, etc. You know you can get to what you need because all the logic isn't in Tcl.
I know, I know, the right answer would be "well, don't use X technology, make sure its a toolkit application", but we don't always have that luxury. 😊
