incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: Data model names, reloaded
Date Mon, 24 Aug 2009 15:21:43 GMT
IMO the window for making this kind of change has passed.  We've
talked about finalizing the 0.4 api weeks ago, we got a beta out with
it, and it does the job.  The timeline wasn't a surprise to anyone
paying attention to the list.  It's time to move on.

-Jonathan

On Fri, Aug 21, 2009 at 1:36 PM, Evan Weaver<eweaver@gmail.com> wrote:
> I think the below scheme successfully avoids the current
> misconceptions, and addresses the issues raised in the previous
> thread.
>
> The names are memorable and short, Anglo-Saxon-style, and take
> advantage of existing database concepts in non-conflicting ways. They
> are not ambiguous or novel. They descend step-by-step from the
> container to the thing contained.
>
> Proposal 2:
>
>  Database
>  Record set
>  Record (w/key)
>  Field set
>  Field
>
> Notes:
>  * Database is the same as in SQL/CouchDB/MongoDB
>  * Record set is based on "record", below. It expresses a container of
> unique rows, without the BigTable baggage (see PS).
>  * Record is the same as row, without the relational baggage.
>  * Field set is based on "field", below, and parallels "record set".
> It expresses a container of unique fields.
>  * Field is the same as in CouchDB, and does not carry the SQL baggage
> of "column", or the relational-theory baggage of "attribute".
>
> I think if we adopted these, we would quickly move from "most
> confusing data model" to "least confusing", based on my research into
> other popular terminology
> (http://markmail.org/thread/6vys3hk774zcrd6v).
>
> Evan
>
> ----
>
> PS. The implementation of column families hasn't changed from
> BigTable, but the use in modeling has. Common Cassandra designs are
> more row-oriented than column-oriented.
>
> With that in mind, keyspace, row, and super-column could also each be
> called column family. They all have sets of related columns in them,
> among other things. Everything but the column itself is some kind of
> "column family". This is a big stumbling block.
>
> I want a new user to be able to look at any level and answer "what is
> the immediate container of this object?" If they can't do that, then
> the term is ambiguous.
>
> --
> Evan Weaver
>

Mime
View raw message