At 9:42 AM -0400 11/2/07, Samuel R. Neff wrote:
I like the term virtual 'cause that's exactly what they are.. a table that
does not really exist in the db and is provided by some other system. This
is not inconsistent with other DBMS's which use terms like "virtualized
view", both are tables that are not linked to underlying physical data. The
fact that the mechanism which provides these tables is different does not
mean they are not both validly virtual tables.
I think the real problem here is "virtual" is a broad enough term
that it can validly apply to a broad spectrum of situations, which
can differ a lot.
At the very least, "virtual" is very applicable both to a SQL view
and to a module whose interface looks like a SQL table, and so to
apply the term to just the latter would cause confusion.
Therefore, my primary recommendation is to use any reasonable term
that is *not* spelled "virtual", not because "virtual" doesn't
describe what we're talking about, but because "virtual" is too broad
and causes confusion.
At 7:37 AM -0700 11/2/07, Trevor Talbot wrote:
It's simply an interface that looks like a table.
Having thought about the matter more, perhaps the
table-like-module-API feature could be called "interface table" then.
In some respects, "interface" is very broad too, but then so is
"table", however, I see it more important to not use the term
"virtual" here.
At 8:08 AM -0600 11/2/07, John Stanton wrote:
To my mind "virtual" means something different. "Foreign" would be
a more intuitive name.
That would also work for me. In fact, "foreign" is arguably better
than "federated", since "federated" also means to take multiple
databases and make them look like one.
And that is something that SQLite arguably does natively, where each
file is a database, and a collection mounted at once being a
federation thereof.
At 7:37 AM -0700 11/2/07, Trevor Talbot wrote:
Terms like "foreign" and "federated" conjure up images of physical
tables that reside in external databases, which is not at all what
this feature is.
Maybe or maybe not.
The relational model of data is intended to abstract the physical
storage mechanism away from the user, such that users just see
tables/relvars which they can run queries on and update the values
of, and how this is implemented behind the scenes in terms of
physical data formats or locations of data is something they
shouldn't need to be concerned with.
So in that respect, all of normal tables (real|base relvars), which
conceptually store the data themselves, and normal "views" (virtual
relvars), which conceptually have their data stored in other, normal
tables, these are all just tables/relvars to the user.
I now bring up a broader matter for consideration ...
If SQLite's table-like-module feature is meant to be like a normal
table in all ways but for its implementation, I would suggest
considering looking at this whole issue in a different way, that
SQLite supports multiple "engines".
When you define a database in SQLite, you also indicate what "engine"
you want to implement it with. SQLite has a built-in default engine,
what normally gets used, or perhaps the file vs memory could be
considered 2 engines. The third-party modules such as we were
discussing would each then provide additional engines to choose from
beyond SQLite's standard built-ins. For backwards compatibility or
simplicity, if schema designers don't explicitly indicate an engine
to use, they get SQLite's built-in by default.
Now while I'm not going to argue any merits of MySQL as a DBMS, it
can still serve as an example of the concept, with its multiple
engine types, eg InnoDB vs Falcon or what have you. Other DBMS may
have similar concepts.
That said, and particularly since SQLite is already supports multiple
databases under a common transaction, I strongly recommend that the
pick of engine is applied at the level of a whole database, not at
the individual table level. Note that I consider a database to be
the widest range of multi-table database constraints, such as foreign
keys, because all of its parts are always defined and live together.
-- Darren Duncan
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
