Back-end to Front-end: a SQL developer’s perspective

More SQL than Python-related, but in fact the immediate inspiration came from this month’s PyMag, which is a bit database-oriented. In his article on good practice in database design, Brian Jones touches on an issue which I’ve felt many times before. There are, let us say, two kinds of developer: those who are primarily interested in the front-end and for whom a database is merely a convenient back-end store; and those who are primarily interested in the data, and for whom any front-end is merely a means to view that data. Obviously I’m polarising the positions here, but it’s surprising how often you can look at a third-party app and get an idea of which camp its developers belong to.

I style myself a database developer. This doesn’t mean I despise front-ends and prefer to look, Neo-like, at streams of data falling in green down my screen. (Although sometimes…) Rather, it means that I’m much more concerned about the data structures and their interactions at the database level, and keen that the UI do a good service by the data. This may of course reflect my almost complete lack of visual design flair: the best thing you can say about my interfaces is that they are workmanlike and competent, conforming as far as possible to established UI guidelines. They certainly don’t have any kind of panache.

To some extent this also reflects in my slowness to take up the various ORMs on offer, although I have recently started using Elixir for a personal project, and found it very workable. In general, though, I prefer my data raw, not cooked, and the typical examples of ORMs tend to be aimed at people who find data a bit of an embarrassment and want to get it out of the way as quickly as possible :)