Data Models and Query Languages

DATA MODELS & QUERY LANGUAGES the model you pick shapes what's easy and what's painful THREE SHAPES: RELATIONAL (tables tied by joins) · DOCUMENT (one nested tree) · GRAPH (vertices + edges). data is layered app-object → model → bytes; the model is a deep choice. 1 · ONE RÉSUMÉ, TWO WAYS (a one-to-many tree) a profile = one person with MANY jobs & MANY schools. RELATIONAL — normalized, joined users id | name 1 | Bill positions user_id | job 1 | CEO Initech education user_id | school 1 | MIT joined by user_id DOCUMENT — one JSON tree { name: 'Bill', positions: [ 'CEO @ Initech', 'CTO @ Hooli' ], education: [ 'MIT' ] } + LOCALITY: the whole tree in ONE read; matches the app object. BUT company / school / skill are many-to-ONE refs (many people → one company) → the document model has weak joins, so you emulate those joins in app code. that's exactly where relational shines. 2 · WHICH MODEL WINS? DOCUMENT · schema-on-READ (flexible, heterogeneous items) · locality — one seek reads the whole thing · shape matches app objects (a tree) – weak joins, many-to-many is awkward RELATIONAL · schema-on-WRITE (the DB enforces it) · great joins — many-to-one & many-to-many – object-relational impedance mismatch (ORM glue) schema-on-read vs schema-on-write = dynamic vs static typing. CONVERGENCE: SQL got JSON columns; document DBs got some joins. pick by the SHAPE of your data — self-contained tree → document; richly cross-linked → relational. 3 · DECLARATIVE vs IMPERATIVE IMPERATIVE — you spell out HOW result = [] for animal in animals: if animal.family == 'Sharks': result.append(animal) // step by step, you loop & mutate DECLARATIVE — you state WHAT (SQL, CSS) SELECT * FROM animals WHERE family = 'Sharks'; the optimizer picks HOW → hides implementation, enables parallelism, and the DB can get faster underneath you without you rewriting a line. MapReduce sits between: a declarative frame around imperative map / reduce functions. 4 · GRAPHS — when many-to-many is EVERYTHING social graphs, road networks, the web: model as vertices + edges. Lucy Alain Idaho USA Beaune France born_in within born_in within a graph makes "who emigrated US → Europe?" natural — even though the US uses states and France uses regions (different granularity is just more edges). two flavors: PROPERTY GRAPH (Neo4j, query in Cypher) · TRIPLE-STORE / RDF (subject–predicate–object, query in SPARQL). graphs win on EVOLVABILITY: add a new edge type with NO schema migration. JARGON, DECODED relation/tuple = table/row · normalization = store each fact once, reference it by id · impedance mismatch = app objects don't match flat tables (ORMs bridge it) one-to-many = a tree (résumé → jobs) · many-to-one / many-to-many = shared references (people → one company) — relational/graph turf · locality = related data stored together schema-on-write = DB enforces structure at write · schema-on-read = structure interpreted at read (flexible) · declarative = say WHAT · imperative = say HOW vertex/edge = node/relationship · property graph = Neo4j + Cypher · triple-store = (subject,predicate,object) + RDF/SPARQL · the semantic web's data model