Origin of SQLSEQUEL: A STRUCTURED ENGLISH QUERYLANGUAGE (1974)by Donald D. Chamberlin
Origin of SQLSEQUEL: A STRUCTURED ENGLISH QUERYLANGUAGE (1974)by Donald D. Chamberlin"However, there is also a large class of userswho, while they are not computer specialists,would be willing to learn to interact with acomputer in a reasonably high-level, non-procedural query language."
SQL is User Interface● Its not an API○ So thats why we need an ORM tool...● Its not a protocol● Its not even designed for programmers● It was however derived from anotherdatabase CLI called SQUARE, that looks abit more like a protocol:○ NAME, SAL EMP DEPT, MGR (TOY, ANDERSON)VS○ SELECT NAME, SAL FROM EMP WHERE DEPT = TOY AND MGR = ANDERSON
The command line user interface isnot an API● Leaking logic to other languages● Dynamically generated code is hard to debug● Security issues○ Escaping is a horror scene● Large overhead○ Process launch overheads○ Parse overhead○ Command generation overhead● Fragility○ Its more prominent with a GUI, but CLIs are not much better○ Have you ever tried to maintain a moderately sizedGreasemonkey script? Its a nightmare!
SQL is a bad UI by todays standards,but its even worse as an API● Fails to separate concerns○ Changing a query to improve performance may involvebreaking business logic○ Requesting a little more data can have a largeperformance hit○ You could not optimize SQL queries with AOP● Leaking concepts○ We leak our entire datastructure to the DB■ That is why a good ORM should generate DDL fromsource code and not the way around○ To solve performance issues we may even leak some ofour business logic. (Aggregating data.)■ To the one thing that is hard to scale
Origin of SQLSEQUEL: A STRUCTURED ENGLISH QUERYLANGUAGE (1974)by Donald D. Chamberlin"SEQUEL identifies a set of simple operationson tabular structures, which can be shown tobe of equivalent power to the first orderpredicate calculus."
Non tabular structures● Connections between people● Ownership relations● Documents (like articles, or presentations)● Data that belongs to a video on YouTube:○ Video○ Comments○ Likes○ etc.● Or more abstractly○ hierarchies○ graphs
So we have non tabular dataCustomerOrder idOrder itemOrder itemOrder itemPayment details
And tables to store that inCustomerOrder idOrder itemOrder itemOrder itemPayment detailsOrdersCustomersItemsPayments
And tables to store that inCustomerOrder idOrder itemOrder itemOrder itemPayment detailsOrdersCustomersItemsPaymentsImpedancemismatch
Data normalizationCustomerOrder idOrder itemOrder itemOrder itemPayment detailsOrdersCustomersItemsPayments
So we normalize our structures● Strongly related data will be scattered all aroundthe hard drive● Performance issues● DBA requests a denormalization○ Again: changing code for performance reason in a waythat potentially breaks business logic● Denormalized data is not indexed by the SQLdatabase○ So we create index tables...● The code using the denormalized tables will bea lot harder to maintain and understand
SQL tries too hard, and we abuse it● SQL databases are more than just tabular datastores○ They enforce a data transfer mechanism■ Why do I need to use TCP/IP to reach a local DB?■ And I even need to authenticate!○ They are indexing services but with very limitedcapabilities.● Why do we use SQL database for○ Storing temporary data locally (maybe files or memory?)○ Storing documents (maybe document stores?)○ Message queues (its terrible for that!)○ Inter process communication (I mean... REALLY?!)
● It enforces a data transfer mechanism so it is reallyslow to run tests using the database○ Even if the data is in an in-memory table○ So we dont test the DB... or only if we must...● On the other hand since its a complicated andfrequently used API, one would be tempted to write acomplete fake○ One that stores stuff in memory, and wont use TCP/IP tocommunicate○ Its almost impossible to do that well, so we dont...● But SQL queries may change in case of performanceoptimization in ways that it breaks logic...It makes testing hard
So what would be better?● A native API instead of string commands. Ishould be able to independently specify:○ what data to collect or save○ how that should be done○ what to index○ the way these commands are sent to the db● The API should be as simple as possible● Schema less data structure○ And if you like static typing, then you can define yourschema as data structures or classes
In an SQL database the datastructure is leaked to the DBSQL DBLeakedstructureAPPDependence
That is the primary reason weintroduced the DB LayerSQL DBLeakedstructureAPPDependenceDBLayerDependence
A schema less database puts the schema tothe right side of the DB layer boundaryNoSQL DBDataStructureAPPDependenceDBLayer Dependence
And by the way we are hiring:c0de-x.com@devillsroom