Rapid Battle Cards 19–36
| # | Side A | Side B | Deciding rule |
|---|---|---|---|
| 19 | Retention: how long data stays available | Archive: where/how less-active data is moved while retrievable | time requirement → retention |
| 20 | CDC: detect/send changes or deltas | Replication: maintain same data on multiple devices/nodes | delta detection → CDC |
| 21 | Active replication: replicas recreate/store based on operations from peers | Passive replication: primary creates state, propagates to secondaries | single primary → passive |
| 22 | Mirroring: relatively immediate synchronization / coordinated commit | Log shipping: apply transaction logs at intervals | periodic logs → log shipping |
| 23 | Resiliency: tolerate errors and continue | Recovery: restore after failure/loss | continue despite errors → resiliency |
| 24 | Immediate/Critical recovery: automatic/designed continuity or rapid restoration | Non-critical recovery: can wait until higher-priority systems recover | business priority + tolerated restore delay |
| 25 | Technology Support: select/maintain DB technology | Operations Support: manage data/processes technology operates | product/platform selection → Technology |
| 26 | Storage requirement: capacity/retention/access space needs | Usage pattern: transaction/time/location/priority workload behavior | peaks/valleys → usage pattern |
| 27 | Backup: create protected copy | Recovery test: prove copy/procedure actually restores | unreadable/untested backup is not proven protection |
| 28 | Physical configuration audit: installed per detailed design | Functional configuration audit: required functional/performance attributes achieved | installation correctness vs achieved function |
| 29 | Refresh: copy all data | Merge/delta: apply only changed data | huge object + little change → merge/delta often more efficient |
| 30 | Availability: can the DB be used? | Speed: how quickly does it respond? | performance requires both |
| 31 | Transaction performance: online real-time operations | Batch performance: scheduled jobs within an operating window | scheduled completion window → batch |
| 32 | Test data: generated/sampled/purpose-built | Production data: real operational data | protected prod-derived data may require masking |
| 33 | Migration: transfer storage/type/system with little conceptual change | Integration: transform/combine meaning across systems | extensive semantic combination → integration concern |
| 34 | Data Audit: evaluate compliance/method/contract criteria | Data Validation: evaluate quality/usability acceptance | compliance → audit; fitness for use → validation |
| 35 | Storage metric: capacity/objects/queues/usage | Performance metric: transaction/query/API performance | measure subject determines family |
| 36 | Operational metric: retrieval/backup/DQ/availability process health | Service metric: issues/escalations/resolution time | support-ticket flow → service |
Rapid discrimination
- autonomous DBs, one combined view, no duplicate persistence → Federated
- monthly reporting scans a few columns across millions of rows → Column-oriented / OLAP-like
- backup job succeeded but nobody restored it → recoverability unproven
- direct Production patch because “urgent” → environment/change-control violation
- old records must remain retrievable → retention/archive, not purge
- send only rows changed since timestamp → CDC
- apply logs to secondary every 15 minutes → log shipping
- isolated exploratory area with no Production writes → Sandbox
Source range: pp. 186–208.