SQLBatman wrote recently about how database triggers suck. It’s pretty funny, and it made me stop to think. What would it have been like to sit in the first meeting where somebody decided to implement triggers inside a database server?
…
Manager: “Alright, everybody’s here, let’s get started. First item on the agenda: how’s that self-tuning piece coming along? It’s going to be ready for this version, right?”
Developer A: “Yep, lookin’ good. It’ll be completely self-tuning.”
Manager: “Okay, great. Next up, we’ve got a new feature request from one of the customers. They want to be able to permanently attach SQL code to tables, and when someone inserts, updates or deletes a record, they want something to happen automatically.”
Developer B: “In the foreground, or in the background? Like, do they want to kick off some kind of background processing?”
Manager: “Doesn’t say. Should probably be in the foreground though.”
Developer A: “Okay, so we’ll keep the transaction open until their SQL code finishes. What kinds of stuff do they want to happen?”
Manager: “Doesn’t say. I’m sure it’ll be small, though – they wouldn’t want some kind of ugly processing going on with every transaction.”
Developer B: “Who the hell would want to do that?”
Manager: “They swear it’s only a short-term thing – they often need to temporarily insert some business logic in there until they can recode their application to make the database updates themselves.”
Developer B: “Ah, okay. How do they want to return results about what got modified?”
Manager: “They want detailed logging returned to the query window showing what got affected. Otherwise, they’d never be able to troubleshoot if the engine kept making changes behind the scenes, right?”
Developer A: “Yeah, that’d be a nighmare. I know exactly what they want. When they run a query, they want a nice grid listing all of the affected changes to records, with like a before-and-after comparison so they could instantly tell what the trigger did.”
Manager: “Exactly.”
Developer B: “And let’s add some client stats on the performance impact too, so they can see how much of the performance slowdown is due to the trigger versus their bad code.”
Developer A: “No problem. You code the part inside the engine so that the triggers do their thing, and I’ll code the user interface part as soon as I’m done with the self-tuning stuff. How hard can it be?”
… (one month later) …
Manager: “Alright, status update time. Everybody’s here except Developer A. Go get that son of a – ”
Developer A: “I’m here. I’m under the table.”
Manager: “What the – you’ve got a mattress down there?”
Developer A: “Yeah. I’ve been sleeping here.”
Manager: “Why?”
Developer A: “I’ve been a little behind lately, so I’ve been staying late to catch up coding.”
Manager: “WHAT?!? Don’t tell me the self-tuning stuff isn’t going to make the release date.”
Developer A: “Depends – when’s the release date?”
Developer B: “Aww, man, what about the trigger user interface? The results grids showing what the trigger did?”
Manager: “You morons! We have to ship Friday! Marketing’s already bought all the ads and rented a big space for the party. We’ll get the self-tuning stuff and the trigger user interface in the next release.”
Developer B: “Everybody’s going to hate us! They’re going to say they need penicillin after using our product!”
– 
