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