Mailing-List: contact cassandra-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of mobiledreamers@gmail.com
 designates 209.85.132.240 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=c2IR9LOjDWrHlbqvDCmxsvhp0eM0vT6LvaSEowF5ZhnOHAZQ8fuFVvsj5233Zwcs3Y
         orTm035xRhkXsOLMlpS6WVfxgzwTNML7rwKS/TI8XTHhOjC82KFVlTJKWes7nX77KFlk
         buCAdjPdkW7S+6Dw9CY2p4TXfPsmCWmHdIuo0=
MIME-Version: 1.0
In-Reply-To: <e06563880908240821l7e6c52d0oad87fd91762c724f@mail.gmail.com>
References: <b6f68fc60908211136w97b9df7p9b7d7c8503adabc0@mail.gmail.com>
	 <e06563880908240821l7e6c52d0oad87fd91762c724f@mail.gmail.com>
Date: Mon, 24 Aug 2009 21:22:23 -0700
Message-ID: <c1870d60908242122l17a5291ak6204fb32ad2f18c6@mail.gmail.com>
Subject: Re: Data model names, reloaded
From: mobiledreamers@gmail.com
To: cassandra-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=001636ed6f6b67bacc0471efae81

--001636ed6f6b67bacc0471efae81
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

i agreeeven Cassandra .3 was very usable

On Mon, Aug 24, 2009 at 8:21 AM, Jonathan Ellis <jbellis@gmail.com> 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
> >
>


-- 
Bidegg worlds best auction site
http://bidegg.com

--001636ed6f6b67bacc0471efae81--