Previous thread about misconceptions is here: http://markmail.org/thread/bazylonda7tofcnv
On Fri, Aug 21, 2009 at 11:51 AM, Arin Sarkissian<[email protected]> wrote: > 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 >> > -- Evan Weaver
