There’s a lot of debate in application development circles over various sundries such as column naming schemes and framework implementation details. Well, I’d like to clear all that up.

See, there are more application frameworks than grains of sand on the entire planet Earth, and each one of them has a different philosophy and API for creating database objects. Rails, Django, Turbogears, Zope, Zoop, Drupal, Catalyst, Nitro, Nuke… holy fucking Christ, stop it already! Apparently each individual person who glanced at a programming book last week thinks that language is the epitome of cognitive design, yet is incapable of operating a search engine, so decides to shit out an application framework collecting his or her various insights and pet peeves into a pulsating monstrosity that inevitably and mysteriously gathers followers, like an insidious cult.

This is relevant because in the corporate world, or even in Fred’s shanty under the bridge, there’s likely data that existed before these frameworks were a glimmer in some unkempt bearded-dude’s rheumy eye. Most of the good frameworks provide the ability to assign column and table names to framework instances and override the lazy and wrong defaults, but only after sacrificing a goat and seven chickpeas to an HP 5L while undulating erotically to the Transformers theme played by an orchestra comprised entirely of toothless hobos slobbering over filthy kazoos. So, either through sheer laziness, incompetence, arrogance, shortsightedness, or other applicable derogatory adjective, the programmer decides to dispense entirely of the old data and create something which is obviously better. This happens whether or not the previous database was properly normalized and scalable, will always introduce at least one fundamental incompatibility with later merging the old data, and assumes the new application is “The Right Way” even when it obviously isn’t. This is true because any subsequent developers will repeat the same process, regardless of existing documentation quality, code readability, application functionality, or protests from other departments.

“But it’s easier to use the framework this way!” they bleat.

“This should be in Rails/Django/Nuke instead of Rails/Django/Nuke!” they helpfully suggest.

“Applying a table prefix is too hard!” they whimper.

“I want a lollypop!” they cry.

Look you fucking pansy twats, I get it, ok? You get wet when you glimpse a Rails book, or experience instantaneous orgasm in the mere presence of anything written in Python, but you know what? My data has been here for years, and will exist after the OCaml developer scoffs at your Ada app, promptly scraps it in favor of his pet project du jour, and lambastes your poor judgment to passing alleycats. You fucking code your app to the design spec and accommodate the data, not the other way around. I know you’re hot shit, with degrees and accolades and “community awe” dribbling down your leg, but fuck you! Without proper database design backing your Holy App ™, it’ll likely transform the datastore into a smoldering ruin if more than your mother and yourself actually use it for more than five minutes.

Every framework has its own suggested practices backed by one or more database “abstraction” layers. If we just let every jackhole with a keyboard decide what the data should look like, every company would have fifteen separate incompatible databases for the same fucking Twinkie Jockstrap storefront. I know you’re busy scratching you balls, but here’s a hint: there’s only so many ways to sell Twinkie Jockstraps, the company sold them before you fellated your Language Theory professor, and the eight years of data they’ve normalized and optimized to sheer perfection cares not for your qualms over raping whatever application framework happened to molest your common sense this morning.

So when your DBA approaches you with a tire iron and happily “suggests” a few columns be renamed to fit the naming scheme, and that you should use a table prefix to avoid namespace pollution, and that your table structure was shat out of a dyslexic monkey high on meth, you better fucking listen. Because he’s heard your pithy excuses from fifteen other worthless fucks who’ve come and gone, whose legacy has littered the database with uncounted steaming piles of nonsensical excrement, and there’s five departments breathing down his neck to somehow create a reporting view that seamlessly cobbles everything together and includes New Car Smell.

Don’t push him, because he will fucking kill you.

DBA Angry!
Tagged on:                         

9 thoughts on “DBA Angry!

  • Mr. Thomas, I regret to inform you that your words will never reach the ears for which they would do the most good. Everyone knows that Pythonistas and Rubyists start twitching and convulsing uncontrollably when they go to a site built in PHP!

    “What do you mean, ‘It works?’ Who cares?! It’s so UUUUUG-LEEEEEE!”

    By the way, you ought to know that your math-based spam filter will block out liberal arts students in addition to robots. Intentional…?

  • As a half-DBA / half-wide-eyed-Python-groupie (a hybrid you may find unholy), I recommend SQLAlchemy as an ORM. It’s a bit more complex than your average ORM, but treats the database with all due courtesy, respect, and deference.

  • I’ve never read an atricle that as spot on as this one! ORMs are becomming a fad and people think you get get a perfect database schema at a drive-through. Pretty soon you’ll see “The ORM Corner” with Dane Cook on MTV or FuelTV or somthing. The scandelous part is that they can be pitched as good ideas. But the reality is they really just swipe the dirt under the rug for a company. What makes developers great is if they man up and take responsibility for their app. If somebody was paying me to write code, I’d be damn sure that I knew the ins and outs of everything it relates to, including the DML DDL SQL etc. it generates. Unfortunately, because they’re only human coders would rather make bells and whistles then be responsible. Hopefully this fad will phase out and app developers will learn the difference between “interfacing with better technologies” versus “interfacing with technologies better.”

Comments are closed.