Ok, Let's recap:

• Relational database (SQL) tables are records. We can view them (in our heads) as record type definitions.
• JOINS define (some kind of) derived union types.
• SQL CROSS JOINS are full cartesian products, i.e. union types where no name folding/aliasing is done by the imaginary type system

How can we model that in php?

Classes (and objects) are records. Arrays are records too. Both are candidates for doing the job. We need to be able to somehow represent this (meta) type information and manipulate it. The aim is to have a natural feeling/looking abstraction of the database in php. It should be flexible enough, for us to modify the relations at runtime, as we need. It should allow us in the long run to have a near optimal speed and not too much complications in the end code. That is a tough cookie.

I must admit, I'm doing it too. But why oh why, people thing that they must use an sql server, when writing a web application framework. It is beyond me.

Some will say, "Well my/pg/ms/any sql server is fast, it it there, it is ubiquous, flexible and everyone is doing itr, so you can find books about it.

Let's tackle these pros one by one in our context.

Fast

Indeed, it can be. SQL server software is usually designed to work with vast amounts of data, stored on some secondary storage. Relational data can be organised, searched, extracted fast. Sure. But. There is always one. A web application framework doesn't know the exact nature/model of the data. It usually builds a palette of primitive types, then does some magic to join those types per application type. You'll find object-relational mappings, sql synthesis algorithms, others, whend dealing with this problem.

In this scribble I'll discuss an implementation of different topological structures, which can be used for indexing different "relation systems", for example trees for menus, book structures, etc... graphs for caching links between pages.

We can split the problem into two main subproblems. First, navigation and queries withing a single relation domain. For example local table of contents for a section in a book. Second is higher order or inter-domain queries. For example: given a node, determine the all related nodes, ordering them by their distance from the node, based on taxonomy, their position in a book(s), and their position in the site's "link web". We should be able to implement second and hier order based queries, based on the results of these two basic problems.