According to Wiki, Procedural Justice (PJ) means:

Procedural justice is the idea of fairness in the processes that resolves disputes and allocates resources.

To me, this concept of PJ should be introduced to database administration domain as well, I’ll use the following example to illustrate the necessity.

As a DBA, we feel the most pressure during a performance trouble-shooting time, esp. when there is a “Solve it ASAP” requirement.

Because of this “solve it ASAP” requirement, I have observed one common pattern of performance trouble-shooting in most of my work environments. The scenario is almost identical everywhere: an important application (be it a report for senior management or a business application used by some VIPs) suddenly slows down, and this performance issue is usually tracked to be a complex query (such as multiple table joins or complex sub-queries etc). After some checking, 1st-tier support staff will start to recommend adding one or more compound indexes to one or few concerned tables, and these indexes will cover every column used in one or more where clauses.   The proposed solution usually works like a magic. However, to me, this blindly-adding-index approach implants some seed of debt that we need to pay back later due to obvious reasons, such as more index space, more index maintenance time and more overhead cost for insert/update/delete operations on the tables. These costs are not obvious and will not trigger immediate concerns and thus are usually overlooked by stakeholders.

I have seen in some commercial applications, there are multiple compound indexes on a same set of columns of a table, the only difference is that each index starts with different sequence of the columns, and as a result, the indexes consumes about 75% space of the whole table size, and this occurs to most of the tables in the database.

These hidden costs are not an immediate eye-sore, and the impact of the costs is counter-crossed by upgrading to larger, better, yet more expensive I/O storage hardware and the whole hardware system is usually short-lived because of the continuously-added “costs” one way or another.

I am not saying adding index is NOT the right approach, I am just questioning whether the right/fair procedure is followed to arrive to “adding index” solution. Most of the time, there is no right procedure, and the worst part is: once an index is added, it will never be dropped.

This phenomenon prompts me to think that in the “jurisdiction of database administration”, do we need some procedural justice before we come to a solution? or should we care more about the result from the solution without worrying about the procedures to arrive at the solution? This can be a long topic and needs more discussions from both pro and con perspectives.

But I believe a proper procedural justice is necessary for a few reasons:

1. Ensure that due diligence is given to take care of the solution quality.

2. No DBA can abuse his/her “administration privilege” which can damage the whole jurisdiction by error/negligence/carelessness/intention.

3. Build a trust-worthy and audit-proof administration culture/protocol.

Procedural justice does not necessarily only apply to performance trouble-shooting procedures, it can also apply to any  DBA decision procedures that may impact the long-term well-being of database systems, such as a decision whether to use 3rd party tool or to develop in-house tool, whether to create a pure t-sql solution or to create a SSIS based solution, and whether to use Maintenance Plan to do database maintenance or to develop customized solution for the work, etc.

From a big picture perspective, I believe the procedural justice is a corner stone to ensure the lowest administration cost yet the best possible administration quality in long term.