Deep Battle Cards A–D
A — Database Technology Support vs Database Operations Support
Definition: Technology Support selects, installs, configures, maintains, and monitors database/storage technology. Operations Support manages stored data and the operating processes using that technology.
Purpose: separate platform stewardship from stored-data service/lifecycle stewardship.
Inputs: technology standards/requirements vs criticality, SLAs, usage, lifecycle/service requirements.
Outputs: supported DBMS/storage platform vs reliable operating data service/evidence.
When used: product/platform selection/configuration → Technology; backup, recovery, performance, environment operation → Operations.
Common confusion: one DBA may do both; the activity controls the answer.
Scenario: selecting a DB engine = Technology; testing restores = Operations.
Exam trap: a product name in the stem does not automatically make it Technology Support.
Memory hook: Technology chooses/maintains the engine; Operations keeps the service alive.
Source: pp. 166–168, 180–203.
B — Production vs Application vs Procedural vs Development DBA vs NSA
Definition: Production = production reliability/performance/recovery; Application = application DBs across environments; Procedural = stored DBMS logic; Development = design/sandbox/special-use development; NSA = storage-array infrastructure.
Purpose: route the problem to the responsibility implied by the work.
Inputs: incident/change/design object.
Outputs: appropriate ownership/action.
Deciding distinction: primary object of responsibility.
Scenario: trigger performance issue → Procedural DBA; failed storage array → NSA.
Exam trap: do not assign storage hardware to Production DBA merely because Production is affected.
Memory hook: Production runs; Application follows the app; Procedural codes inside DB; Development designs; NSA stores beneath.
Source: pp. 170–173.
C — Centralized vs Distributed vs Federated vs Non-federated
Definition: Centralized = one system/place; Distributed = multiple nodes; Federated = autonomous constituent DBs coordinated/presented together; Non-federated distributed = centrally controlled components.
Purpose: match location/autonomy/integration requirements to topology.
When used: one place → centralized; many nodes → distributed; autonomous sources mapped together → federated; centrally controlled distributed components → non-federated.
Common confusion: distributed does not automatically mean federated.
Deciding distinction: number of nodes first, then autonomy/control.
Scenario: three departments retain local DB ownership but users see one view → federated.
Exam trap: federation does not require copying all source data into a new store.
Memory hook: Distributed asks WHERE MANY; Federated asks WHO STILL CONTROLS.
Source: pp. 174–176.
D — ACID vs BASE vs CAP
Definition: ACID = strong transaction properties; BASE = availability-oriented/eventually consistent processing posture; CAP = trade-offs among consistency, availability, partition tolerance in distributed systems.
Purpose: distinguish transaction guarantees from consistency posture and distributed-partition decisions.
When used: commit/rollback/all-or-nothing → ACID; temporary stale state acceptable for availability → BASE; network partition forces consistency/availability choice → CAP.
Common confusion: CAP is not a third transaction model parallel to ACID and BASE.
Scenario: POS payment must commit atomically = ACID; globally distributed cache tolerates stale copies = BASE context; partition forces C/A choice = CAP.
Exam trap: CAP has nothing to do with modeling cardinality.
Memory hook: ACID = transaction promise; BASE = softer consistency posture; CAP = partition trade-off.
Source: pp. 176–180.