From 020c1e77489b772f854bb3288b9c8d2818a6bf9d Mon Sep 17 00:00:00 2001
From: EuAndreh <eu@euandre.org>
Date: Fri, 18 Apr 2025 02:17:12 -0300
Subject: git mv src/content/* src/content/en/

---
 src/content/blog/2021/04/29/relational-review.adoc | 144 ---------------------
 1 file changed, 144 deletions(-)
 delete mode 100644 src/content/blog/2021/04/29/relational-review.adoc

(limited to 'src/content/blog/2021/04/29/relational-review.adoc')

diff --git a/src/content/blog/2021/04/29/relational-review.adoc b/src/content/blog/2021/04/29/relational-review.adoc
deleted file mode 100644
index 4b53737..0000000
--- a/src/content/blog/2021/04/29/relational-review.adoc
+++ /dev/null
@@ -1,144 +0,0 @@
-= A Relational Model of Data for Large Shared Data Banks - article-review
-
-:empty:
-:reviewed-article: https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
-
-This is a review of the article "{reviewed-article}[A Relational Model of Data
-for Large Shared Data Banks]", by E. F. Codd.
-
-== Data Independence
-
-Codd brings the idea of _data independence_ as a better approach to use on
-databases.  This is contrast with the existing approaches, namely hierarquical
-(tree-based) and network-based.
-
-His main argument is that queries in applications shouldn't depende and be
-coupled with how the data is represented internally by the database system.
-This key idea is very powerful, and something that we strive for in many other
-places: decoupling the interface from the implementation.
-
-If the database system has this separation, it can kep the querying interface
-stable, while having the freedom to change its internal representation at will,
-for better performance, less storage, etc.
-
-This is true for most modern database systems.  They can change from B-Trees
-with leafs containing pointers to data, to B-Trees with leafs containing the raw
-data , to hash tables.  All that without changing the query interface, only its
-performance.
-
-Codd mentions that, from an information representation standpoint, any index is
-a duplication, but useful for perfomance.
-
-This data independence also impacts ordering (a _relation_ doesn't rely on the
-insertion order).
-
-== Duplicates
-
-His definition of relational data is a bit differente from most modern database
-systems, namely *no duplicate rows*.
-
-I couldn't find a reason behind this restriction, though.  For practical
-purposes, I find it useful to have it.
-
-== Relational Data
-
-:edn: https://github.com/edn-format/edn
-
-In the article, Codd doesn't try to define a language, and today's most popular
-one is SQL.
-
-However, there is no restriction that says that "SQL database" and "relational
-database" are synonyms.  One could have a relational database without using SQL
-at all, and it would still be a relational one.
-
-The main one that I have in mind, and the reason that led me to reading this
-paper in the first place, is Datomic.
-
-Is uses an {edn}[edn]-based representation for datalog
-queries{empty}footnote:edn-queries[
-  You can think of it as JSON, but with a Clojure taste.
-], and a particular schema used to represent data.
-
-Even though it looks very weird when coming from SQL, I'd argue that it ticks
-all the boxes (except for "no duplicates") that defines a relational database,
-since building relations and applying operations on them is possible.
-
-Compare and contrast a contrived example of possible representations of SQL and
-datalog of the same data:
-
-[source,sql]
-----
--- create schema
-CREATE TABLE people (
-  id UUID PRIMARY KEY,
-  name TEXT NOT NULL,
-  manager_id UUID,
-  FOREIGN KEY (manager_id) REFERENCES people (id)
-);
-
--- insert data
-INSERT INTO people (id, name, manager_id) VALUES
-  ("d3f29960-ccf0-44e4-be66-1a1544677441", "Foo", "076356f4-1a0e-451c-b9c6-a6f56feec941"),
-  ("076356f4-1a0e-451c-b9c6-a6f56feec941", "Bar");
-
--- query data, make a relation
-
-SELECT employees.name AS 'employee-name',
-       managers.name AS 'manager-name'
-FROM people employees
-INNER JOIN people managers ON employees.manager_id = managers.id;
-----
-
-[source,clojure]
-----
-;; create schema
-#{{:db/ident       :person/id
-   :db/valueType   :db.type/uuid
-   :db/cardinality :db.cardinality/one
-   :db/unique      :db.unique/value}
-  {:db/ident       :person/name
-   :db/valueType   :db.type/string
-   :db/cardinality :db.cardinality/one}
-  {:db/ident       :person/manager
-   :db/valueType   :db.type/ref
-   :db/cardinality :db.cardinality/one}}
-
-;; insert data
-#{{:person/id      #uuid "d3f29960-ccf0-44e4-be66-1a1544677441"
-   :person/name    "Foo"
-   :person/manager [:person/id #uuid "076356f4-1a0e-451c-b9c6-a6f56feec941"]}
-  {:person/id      #uuid "076356f4-1a0e-451c-b9c6-a6f56feec941"
-   :person/name    "Bar"}}
-
-;; query data, make a relation
-{:find [?employee-name ?manager-name]
- :where [[?person  :person/name    ?employee-name]
-         [?person  :person/manager ?manager]
-         [?manager :person/name    ?manager-name]]}
-----
-
-(forgive any errors on the above SQL and datalog code, I didn't run them to
-check.  Patches welcome!)
-
-This employee example comes from the paper, and both SQL and datalog
-representations match the paper definition of "relational".
-
-Both "Foo" and "Bar" are employees, and the data is normalized.  SQL represents
-data as tables, and Datomic as datoms, but relations could be derived from both,
-which we could view as:
-
-[source,sql]
-----
-employee_name | manager_name
-----------------------------
-"Foo"         | "Bar"
-----
-
-== Conclusion
-
-The article also talks about operators, consistency and normalization, which are
-now so widespread and well-known that it feels a bit weird seeing someone
-advocating for it.
-
-I also stablish that `relational != SQL`, and other databases such as Datomic
-are also relational, following Codd's original definition.
-- 
cgit v1.2.3

