Some SQL Tricks of an Application DBA

When I started my career in development, my first job was a DBA. Back then, before AWS RDS, Azure, Google Cloud and the rest of them cloud services, there were two types of DBAs:

The Infrastructure DBA was in charge of setting up the database, configuring the storage and taking care of backups and replication. After setting up the database, the infrastructure DBA would pop up from time to time and do some “instance tuning”, things like sizing caches.

The Application DBA got a clean database from the infrastructure DBA, and was in charge of schema design: creating tables, indexes, constraints, and tuning SQL. The application DBA was also the one who implemented ETL processes and data migrations. In teams that used stored procedures, the application DBA would maintain those as well.

Application DBAs were usually part of the development team. They would possess deep domain knowledge so normally they would work on just one or two projects. Infrastructure DBAs would usually be part of some IT team, and would work on many projects simultaneously.

I’m an Application DBA

I never had any desire to fiddle with backups or tune storage (I’m sure it’s fascinating!). Until this day I like to say I’m a DBA that knows how to develop applications, and not a developer that knows his way around the database.

In this article I share some non-trivial tips about database development I gathered along the way.

Check out my 10 non-trival tips for database development ›››

Originally published at https://hakibenita.com on July 27, 2020.