On a lighter note than usual, I thought it was time I weighed in on some of the long standing “programmer holy wars”, but with a little DBA-twist (like a twist of lime, only less delicious). Like any good holy war, this will be full of posturing, pontificating, and political correctness. And I probably won’t even commit to a particular side on some issues. But hey, isn’t that the point?
Battle 1: Tabs vs. Spaces
Text editors and IDEs have long been mature enough to handle “smart tabs” and preference-based tab size. However, you will occasionally have to copy-paste code into a non-code-oriented environment, such as an email or a document, where of course the tab size is based on inches rather than spaces in a
monospace font. I will admit in those rare instances, tabs are annoying. But what is more annoying is the inconsistency you can get when spaces are used incorrectly, especially in the midst of lines in a sad attempt to do some kind of vertical alignment. Plus, if you happen to have a different spacing-size preference than the original code author, you’re now battling that visual discrepancy as you read & maintain said code.
So I prefer tabs. But I won’t fight my team on it if everybody else prefers spaces — that’s what those settings in the editor/IDE are there for! I will happily conform with the best of them. A quick Google says I’m in the minority anyway — which I’m OK with.
Battle 2: The Case for Casing
Certain languages (
SQL) have a historical bent toward ALLCAPS for their keywords and language constructs. Some argue that this is archaic, outmoded, etc. I don’t mind it, working primarily with SQL, but in almost all other languages (
But that’s not really what this battle is usually about. Most often, it’s about your names, i.e. the identifiers for objects/methods/variables/procedures/APIs/etc. that your team and your developers have to come up with on a constant basis. And usually it comes down to
TitleCase (which are often incorrectly used interchangeably! and is apparently better known as
PascalCase, which I just learned today, or possibly re-learned after several years), or
lower_case_with_underscores (which, in another learning moment, I discovered is named
snake_case! How cool is that?). Rarely, if ever, do people argue for ALLCAPS in these areas — it just feels.. obnoxious.
As with any programmer-y topic, you can dive down the rabbit-hole and dissect layer upon layer of nuance in this battle until you’ve lost all semblance of productivity. Because casing is, in some languages, important; while in others it’s simply convention-based, dependent on the abstraction level or family of things you’re talking about. For example, C#
Class names are
TitleCase, and so typically are
object instances are usually
public members can be
private members can be
_underscore_led, or whatever flavors for each that your boiler-plate/template system prefers. Scoped
variableNames are most often camel’d as well, while global constants are typically
CAPS_WITH_UNDERSCORES. And god help you if you ask a team of more than 3 people what their dependency packages’ names should look like.
So in this battle, I have to play Switzerland. I’m not vehemently opposed to any particular flavor of casing, finding it best to work within the conventions of the language and tool-set at hand.
Side-battle: Spacing in Names
That said, I can’t stand names/identifiers with actual white space in them, but that’s a somewhat different battle. Most languages don’t even allow that, but most RDBMSs will happily accept your ridiculous
My Cool Database and its resident
Silly Tables and
Happy Column 1/2/etc. as long as you properly “quote” them (surround them with [square-brackets] or `backticks`, depending on the SQL flavor). If you submit that kind of nonsense to me, I will find you, and I will slap you with a large trout.
Battle 3: ORM vs Stored-Procs (vs Linq?)
This is that little twist-of-DBA as promised. I recently read an interesting post related to this topic, and essentially the point was this: Developers have “won” (won what? I thought were all on the same side!), the ORM is here to stay, and as DBAs/DBDevs, we (you/I) need to build up our understanding of them so that we A) know them even better than our devs, and B) can troubleshoot performance issues with them.
I think there’s some truth to that, and some necessary context as well. Ideally, yes, I would be an ORM expert on whatever 1 or 2 specific frameworks my colleagues are using (
Entity Framework, most likely), and any time there was a potential performance challenge with a app-to-database call, I’d be able to parachute-in and sprinkle some magic dust and make it all better. But I’m also the one DBA (out of approx. 1.3 total), serving 4 teams of 3-6 devs each, so in the immortal words of meme-dom:
Ain’t nobody got time for that!
Now I’m not making excuses. All I’m saying is, the burden of understanding is on more than just one team member or job-role. If your dev team is adapting an ORM, said devs need to learn how it works too — at least enough to help with basic performance troubleshooting. Even if it’s just the ability to extract, from a debug session, the actual T-SQL code that’s being sent to the server, and give me a sample query to analyze for performance bottlenecks.
Let’s step back a bit. It’s all about using the right tool for the job, yes? ORMs are meant for basic CRuD operations and simple data access patterns, right? So why try to build complex business logic into them? Because, like it not, teams do build complex business logic into the data layer — despite our protests and soapbox sermons to not do it. And because the vast majority of applications we’re dealing with are not greenfield. Furthermore, ORMs tend to work best when the data model is well-defined, or the database is modeled well (well-modeled?). And again, we don’t all get to work with unicorns in utopia.
Put it this way: If you want an efficient, performant module of data-layer business-logic against your SQL database, it’s likely going to be a
stored procedure carefully crafted by a DBA/DBDev. Could you achieve the same results from the app layer, using Linq and/or some mix of ORM and code? Probably. Do you have the time and patience to do so? Maybe not.
So once again, I’m Switzerland. Well, preferably a more pragmatic version — what country would that be? Norway? Anyway. Use the methodology that’s the best compromise between “right tool for the job”, “optimized developer productivity”, and “easiest to troubleshoot”. It’s a tough call, but that’s why we get paid.
Until next time!