incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Estes <>
Subject Re: Data model names, reloaded
Date Mon, 24 Aug 2009 15:49:22 GMT
I for one don't mind having a clear distinction from the relational  
language bias that this change might imply.

Maybe I'm a little too NOSQL, but I think that the current naming does  
avoid confusion with relational concepts that could be  
counterproductive in designing correctly to this type of model.

Tim Estes
Digital Reasoning Systems

On Aug 24, 2009, at 10:21 AM, Jonathan Ellis wrote:

> 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<> 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
>> (
>> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message