I think this proposal is sound.
but im still not voting "yes" on changing all the naming.

but, ya, this proposal is much better than all the rest ive heard

Arin

On Fri, Aug 21, 2009 at 11:36 AM, Evan Weaver<[email protected]> 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
>

Reply via email to