1. Relational DBs Basics

2. Formally understood Set theoretic Originally defined with an algebra, with Selection, Projection, Join, and Union/Difference/Intersection Declarative calculus that is based on the algebra and supports large grained queries Clean implementation spec Unambiguous optimization - with its own algebra of query parse tree transformations

3. Structure Schema based - we can leverage this to address volume Tables, rows, columns, domains Keys (PK and CK) FKs Triggers as a catch-all integrity constraint Normalization for formal table minimization

4. Semantics are in queries Relational algebra compliant Queries written in declarative calculus Set-oriented Programmers tend to follow PK/FK pairs Query results are legal tables (Views)

5. Also we get Fixed size tuples for easy row-optimization 2P transactions Table, Row distribution Two language based, with lowest common denominator semantics Security Checkpointing Powerful query optimizers

6. Object-relational DBs This runs somewhat counter to NoSQL trends - we make the data types even more complex We make domains out of type constructors Object IDs A row can be a tuple - or an object, with an object ID and a tuple, making all relational DBs also O-R

7. Object-oriented DBs No tuple rows Blend SQL and the app language This avoids lowest common denominator semantics These bombed, as relational DBs were not O-O And they are tough to optimize