There isn't anything the relational model can not handle for OO data storage. The only thing it can not handle is the behavior/methods/operations/pick-your-term. And by all rights it has no business performing actions on the data since that is clearly business logic.

I'm very new to database-isms,  but I was making my database a very active one (ie, code the business rules into the database as triggers, stored procedures, and tasks; for example, when an alarm gets inserted into the db, a trigger fires off and if the alarm matches a mask in a different table, the database would email me using sqlmail).

Your comment makes me wonder if that is really the way I should do it, so here are my newbie questions:

1. Why separate the business logic into another compartment?  Where/how would it run?

2. Is there a way to pass an event from the db to an application (db says "New Data in table Foo.", instead of the app pulling a dataset every few minutes and detecting changes -- is there a way to do this w/o pulling a whole dataset)?

We're planning on having some events that run every minute, others that run daily, and some others (like the alarms above) that run based on row(s) modified in the table.

Any reason my db should be quiet place of solitude vs a "Active Do-All Buzzing Database"?

TIA,

Thor