Farm Development

Web Frameworks Do Not Make DBAs Happy

A colleague of mine, Shaun Thomas, is one of a few database administrators who manage all our company's databases by monitoring, optimizing, partitioning, building star schemas, etc. The DBAs also maintain standard operating procedures for how to name a column or how to refer to an external identifier. Most importantly, they conduct reviews of your horrid schema changes before you break stuff.

Most web frameworks (Django, Rails, etc) out there abstract away a lot of low level database details since they focus on making life easier for web developers. This is great but it's important to have a way to easily tweak the low level stuff when you need to. In fact, most frameworks kinda leave DBAs in the dust. It looks like Shaun reached his breaking point on this a few weeks ago and the result was a hilarious rant. He does have a good point. The only database abstraction layer I've used that truly keeps the DBA in mind is SQLAlchemy. It adds more complexity to the tool but not in a way that makes your life difficult.

  • Re: Web Frameworks Do Not Make DBAs Happy

    I have no idea why DBAs have put up with this shit for so long. From their DB vendors, that is. What's that, you must insist on presenting the same logical schema to every app that wants to talk to your carefully organized data? Waah waah wah. (Not to imply that many vendors don't offer partial support that these DBA's are just not bothering to use, good or bad.)

    I don't want to hear it if you a) believe you must enforce your one true schema to all clients but b) you insist that the client-side is the appropriate place for this enforcement.

    (Nor is this to imply that there aren't a lot of bad models made by programmers or that DBAs shouldn't review schemas or have system-wide naming conventions. Just a question of subsidiarity, multiple valid viewpoints at the perimeter.)

    SA does give you this sort of mapping support to separate the DBA's vision of the data from the client perspective. Except it still all lives on the client side, so when that glorious central model gets an update, who has to change? Every g**damn client? What was the promise of RDBMs again? We're better than this, programmers know it, and that's why they take on the responsibility that just maybe ought to be in the DB. But at a cost to everyone.

    Rant off.

  • Re: Web Frameworks Do Not Make DBAs Happy

    (I should add, your perspective probably changes depending on whether you see yourself as a DBA who rules the central schema and all who suckle at it, or one who shepherds the perimeter schemas into a productive communal existence. And there will always be degrees of mapping on both sides: I'm not calling for a complete reversal from client to db, I am after all an open-worlder.)

  • Re: Web Frameworks Do Not Make DBAs Happy

    the schema def can live in SQLAlchemy code but it can also live in SQL files and the code can use reflection. I think this is the best approach when a DBA is in charge of defining and maintaining the schema. In fact, for a project I'm on right now, the DBA uses an ERD tool (I forget the name) and that tool generates postgres-specific SQL as well as generates alter statements when the ERD changes. The SQLAlchemy model just uses reflection to get all meta data and only requires minor changes like 3 lines of model code when new tables are added. Actually I think django, rails and most database abstraction layers have decent support for reflection (some more flexible than others).

  • Re: Web Frameworks Do Not Make DBAs Happy

    I must have missed something, I never realized the ORM will allow me to forget about the structure of the database entirely... I thought it was just helping me to access persistent data without db specific dialects/backflips necessary to do basic create/read/update/delete tasks.

  • Re: Web Frameworks Do Not Make DBAs Happy

    ORMs are abstractions and that's convenient but there is going to be something they miss. For example, Django (iirc) does not let you use a compound primary key on a table. Anyway, I just thought Shaun's rant was funny.

Note: HTML tags will be stripped. Hit enter twice for a new paragraph.

Recent Projects

  • JSTestNet

    Like botnet but for JS tests in CI.

  • Nose Nicedots

    Nose plugin that prints nicer dots.

  • Fudge

    Mock objects for testing.

  • Fixture

    Loading and referencing test data.

  • NoseJS

    Nose plugin that runs JavaScript tests for a Python project.

  • Wikir

    converts reST to various Wiki formats.