incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Estes <tim.es...@digitalreasoning.com>
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
CEO
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<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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message