- #1: Build Classes, Not Individual Databases
- #2: Don't Ignore History
- #3: Automate All Changes to Every Database Instance
- #4: Test Every Change to Database Design
- #5: Force Clients to Break Fast When Interfaces Change
- #6: Encapsulate Database Behavior
- #7: Drive Behavior from Information
- #8: Keep a Complete Unit Test Suite
- #9: Build Only What You Need
- #10: DON'T PANIC
- Summary
#6: Encapsulate Database Behavior
Agility pretty much demands an object-oriented and test-driven approach, and databases are no exception. As I’ve mentioned earlier, a database is really an object, and its design is actually a class. Good classes don’t expose their implementation details.
Instead, an interface should express a contract between instances of a class and clients to the same class. The details of how such a contract is fulfilled should not be apparent to any consumer of an object’s services. In database terms, that typically means hiding the majority of your tables from public consumption and exposing access through stored procedures and views (Figure 12).
Having strong encapsulation that hides all the implementation details of a database will dramatically increase the amount of freedom you can exercise in changing its internal design. That, in turn, will substantially reduce your turnaround time on new features.