Mailing-List: contact cassandra-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-Id: <7E71E64C-9533-45CE-929D-91A913538FC7@digitalreasoning.com>
From: Tim Estes <tim.estes@digitalreasoning.com>
To: cassandra-dev@incubator.apache.org
In-Reply-To: <e06563880908240821l7e6c52d0oad87fd91762c724f@mail.gmail.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-2-91339308
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: Data model names, reloaded
Date: Mon, 24 Aug 2009 10:49:22 -0500
References: <b6f68fc60908211136w97b9df7p9b7d7c8503adabc0@mail.gmail.com>
 <e06563880908240821l7e6c52d0oad87fd91762c724f@mail.gmail.com>

--Apple-Mail-2-91339308
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

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


--Apple-Mail-2-91339308--