I Prefer the Network Database Model

A database is a simple thing, software to store and organize data according to some principles.  The
history of databases reveals many different approaches to the problem, and I usually see claims that
the relational model of databases be best; I'm certain that the hierarchical databases are inferior,
despite persisting in what passes for a filesystem nowadays, and I've also read that SQL fails to be
a proper implementation of the relational model; I see issues in the model at my skill nevertheless.

Part of the justification for the relational model is to avoid rewriting database programs after any
changes to the underlying storage, but most high-level languages seem to fit this description today.
As far as I see, the relational model attempts to turn everything into a problem on tuples, but then
I see not how it avoids the issues any other singleminded model eventually hits, and have read about
them at some length.  Supposedly, specification of the underlying storage method suffices to correct
such performance issues, but I see not the appeal in using such high and low levels in this way.  It
seems preferable to skip this and specify the storage model directly, to gain confidence in its time
and space characteristics.  I many times read of that need to analyze the underlying implementations
for queries, to tweak them so they gain desired properties, but this seems bothersome and foolhardy.

The network model, in comparison, represents a database as a generic graph, which can very easily be
represented in natural terms to some language; in many cases, I see no reason for the language to be
separate at all, unlike the relational model interfaces I regularly see.  Thought of this way, I see
the network model as far more comforting and predictable, as structural types are chosen explicitly.
Handling databases larger than working storage is supposedly the whole reason virtual memory exists.

An index, as I understand it, is redundant storage meant to improve the time characteristics of some
database operation; I've read so many times about linear scans of an entire database caused by their
absence.  It seems strictly better to know the characteristics of all such operations ahead of time,
which is only possible by revealing the underlying storage method, and to be more explicit about the
presence or absence of any indices.  It seems completely unreasonable to ignore an index in any way.

Reliable storage is one important point of databases, but I also regularly read about implementation
flaws that can corrupt such databases regardless.  The best way to get reliable storage is to ensure
power won't be cut to the machine unexpectedly, and this is something software alone can't handle; I
believe anyone who can't fulfill that requirement to be playing pretend, generally.  In any case, an
append-only method of storage is clearly superior, and all databases should probably be based on it.

I often see flexibility in changes given as a selling point, but each system I've seen lacks magical
ways to avoid many issues probably inherent to the problem.  I continue to view a bit of forethought
as important for a large database.  Supposedly, ``serious'' databases won't be able to support large
changes to their vast storage pools, regardless, so getting it right the first time seems important.

All of this stated, I have a relatively simple view of how a database should be integrated into some
system.  For longterm storage and recovery, the database should have some external format written as
events are generated.  The working storage should use some appropriate transformation of such events
into objects lacking any unnecessary characteristics; at this point, relations or ``keys'' should be
converted into direct links or whatnot, and any relevant indices should be updated also.  In no case
should the working storage diverge from the longterm storage; in the case of power down or the like,
the working storage should be repopulated exclusively from longterm storage just as when it was done
originally.  I've read about how the append-only method faces growing storage costs, as time passes,
but trimming the storage periodically handles this more than well enough; whether redundant storage,
such as an event negated by a following event, would be cleaned hourly, yearly, or at all depends on
details that also ought to be made explicit for the sake of the system.  I feel I've likely restated
many characteristics of a normal system with a database, but I see no need to involve another system
and language for such simple tasks as these.  Every program only uses its data in a few simple ways.

I believe using explicit data structures to be a superior way to organize data, over anything vague.