Thoughts on the Shape of data

In the original paper on the relational model of databases, the ability to perform unplanned queries
on the database without changing the program is one listed advantage, and generally holds across the
broader declarative model of programming.  I prefer the network model of databases, where everything
is more concrete, specified in terms of exact data structures.  I'm aware that SQL embodies not that
true relational model, although this is largely irrelevant; I found myself wondering what a flexible
database should expose and what it would reward.  I conclude there to be no database where foresight
isn't preferable, no model which can remove its need, and also noted how general high-level programs
already need no changes to run across different environments.  I've read of many accounts where some
SQL database nevertheless needs changes, for one reason or another, alongside queries so unoptimized
they rifle through all data in the system, and it has me wondering about the purpose of such messes.

A simple example of foresight comes to mind: I'm aware of forums which allow accounts to bind single
messages to themselves for emphasis; the questions are the shape the binding should take and whether
it should be bound to the account or the message.  Either approach to the second question has a good
and a bad side, both are rather set in stone at the system's creation, and the choice influences the
other answer deeply.  The obvious solution for most systems assumes that messages will significantly
outnumber accounts, and so minimizes the cost by associating it with the smaller group, and this way
is generally best.  It's unavoidable fact that data has different sizes based on its representation.

Binding such a message to the account brings in the notion of referring to a particular message, and
this requires the ability to distinguish messages from each other, which generally uses a fixed-size
identifier and thus limits the overall size of the system.  By contrast, the one obvious shape of an
association held in the message is an enumeration, Boolean.  Messages must know their accounts also,
but messages are generally variable-length in ways accounts rarely are, and this furthermore removes
most or all notions of global state from the system.  A message may be viewed and processed in total
isolation when the message holds more data.  Data-flow programming and its constraints often come to
mind whenever I mull over these kinds of systems, for global state is always a nuisance.  Adding the
binding to the message also makes the system strictly more flexible, because the binding of a single
message only is one limitation imposed by storing such with the account, and otherwise not inherent.

I like the idea of late binding, and those related ideas, but I simply can't imagine a model whereby
most everything, changing excepted, becomes easier with enough forethought.  An alternative solution
to the same problem is making it easier to build ``sturdy'' and ``fixed'' but still useful programs.
When phrased this way, the answer looks to be humorously self-evident; forethought is always better.
.