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
