Rapid Battle Cards 1–18
| # | Side A | Side B | Deciding rule |
|---|---|---|---|
| 1 | Database: collection of stored data | Instance: execution of DB software controlling storage | “running software context” → instance |
| 2 | Instance: running DB software context | Schema: subset/container of objects, often owner/access-based | schema organizes objects; instance executes software |
| 3 | Production DBA: production operations/reliability/recovery | Application DBA: application-specific DBs across environments | application focus across dev/test/prod → Application DBA |
| 4 | Procedural DBA: stored procedures, triggers, UDFs | Development DBA: design and special-use/sandbox DBs | DBMS procedural logic → Procedural DBA |
| 5 | DBA: database applications/structures/operations | NSA: storage-array hardware/software | array/storage infrastructure → NSA |
| 6 | Centralized: one system/place | Distributed: multiple databases/nodes/systems | multiple nodes / scale-out → distributed |
| 7 | Federated: autonomous component DBs mapped together | Non-federated: centrally controlled distributed components | autonomy is the discriminator |
| 8 | Loose federation: components construct own federated schemas; more source/location knowledge | Tight federation: integrated federated schema constructed/published | shared integrated schema → tight |
| 9 | DB on VM: owner runs DB software on VM | DaaS: provider installs/maintains DB service | who maintains the database is the clue |
| 10 | ACID: strong transaction properties | BASE: availability/flexibility/eventual consistency posture | commit/rollback/all-or-nothing POS → ACID |
| 11 | BASE: processing/consistency posture | CAP: distributed-system consistency/availability/partition trade-off | network-partition trade-off → CAP |
| 12 | Disk/SAN: persistent stable storage | In-memory: processing in volatile memory, loaded/protected through persistent mechanisms | volatile-memory speed → in-memory |
| 13 | Production: mission-critical live service | Development: first controlled place for changes/patches | never develop/test in Production |
| 14 | Test: formal QA/integration/UAT/performance | Sandbox: experiment/POC/user-managed isolated area | hypothesis/experiment → Sandbox |
| 15 | Relational: schema-on-write, structured relations, commonly row-oriented | Non-relational: schema-on-read possible, less constrained structures | predefined tabular schema → relational |
| 16 | Row-oriented: many columns of a row; OLTP | Column-oriented: aggregates across many rows/fewer columns; OLAP | interactive whole-row transactions → row; analytical scans → column |
| 17 | Valid time: when fact is true in real world | Transaction time: when stored fact is considered true in database | real-world truth vs database-recorded truth |
| 18 | Archive: move to long-term storage, retrieve later | Purge: irreversible removal | recoverable later → archive |
Speed drill
Cover Side A/Side B and classify these clues: running DBMS context; autonomous combined view; published federated schema; stored trigger specialist; storage array; POS commit/rollback; formal UAT; analytical scan of a few columns; real-world validity date; recoverable old record.
Source range: pp. 168–188.