incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <>
Subject Re: Fixing the data model names
Date Thu, 13 Aug 2009 01:07:40 GMT
On Wed, Aug 12, 2009 at 7:23 PM, Evan Weaver<> wrote:
> Re. Jonathan on "database": oracle/sqlserver/mysql/postgres call it a
> database.

No.  With a database (ignoring things like user accounts that don't
apply) the difference is that you decide at connection time what
database you want to talk to and once you do that there is no way* to
access data from other databases.  With schemas you have namespaced
objects but you can operate on other schemas w/in the same db.  So
that is the appropriate analogue to cassandra, where once connected
you can operate on any keyspace.

*Yes, I know there are some vendor-specific hacks to make this less true.

 > Re. Jonathan on "columns": it would make more sense if "column family"
> was actually called "sparse table". But super columns break the
> tabular model, so I don't think pretending to be tabular is a good
> answer. Personally I prefer the terms borrowed from document databases
> (I didn't realize that "attribute" was the relational-theory term).
> Maybe "field" and "field set" is better.

Maybe.  Maybe not.  That's my point; if you can't pick something
that's Clearly Better then you might as well leave well enough alone.

> I agree that individually, the current names are technically accurate
> in their specific contexts. But taken as a whole, they make
> practically no sense to someone starting out, as Ryan mentions. I'll
> poke around try to come up with some other possible term sets. The
> point isn't that they are *this* specific set, just that they are
> internally consistent, and analogous to things widely understood.

Analogies are dangerous things.  See the concept-formerly-known-as-table. :)

I'd rather focus on documenting a Pretty Good set of terminology than
try to bikeshed my way to perfection.


View raw message