README.md

@@ -1,3 +1,5 @@
-# relational-documents
+# Relational Documents
 
-Parent documentation for projects that facilitate storing documents in PostgreSQL and SQLite
+This repository contains the source files for the landing page which covers all Bit Badger Solutions-produced document libraries.
+
+Library-level documentation and API docs will be deployed in subdirectories of this site, although the hand-written documentation will be in each library's repository, and the API docs (JavaDoc, PHPDoc, etc.) will be extracted and generated by the appropriate build tools.

concepts/what-are-documents.md

@@ -113,3 +113,6 @@ For now, though, we still need to represent the checked out books. We can use a
 One of the big marketing points for document databases is their ability to handle "unstructured data." I won't go as far as saying that's something that doesn't exist, but the _vast_ majority of data described this way is data whose structure is unknown to the person considering doing something with it. The data itself has structure, but they do not know what it is when they get started - usually a prerequisite for creating the data store. On rare occasions, there may be data sets with several structures mixed together in the same set; even in these data sets, though, the cacophony usually turns out to be a finite set of structures, mixed inconsistently.
 
 Keep that in mind as we look at some of the trade-offs between document and relational databases. Just as your body needs its skeletal structure against which your muscles and organs can work, your data _has_ structure. Document databases do not abstract that away.
+
+
+[prev]: ./a-brief-history-of-relational-data.md "A Brief History of Relational Data • Relational Documents • Bit Badger Solutions"