Ah, so you're arguing that common cassandra designs don't typically use business objects that span multiple column families, and therefore the term "column family" shouldn't be used?
I understand columns in Cassandra, I'm just not familiar with "row-oriented modeling" and "column oriented modeling":-) Even with relational column stores, column groups (or column families) are a storage optimization based on access patterns you expect in queries. They don't affect the primary goals of ER modeling like normalization and capturing RI constraints. On Fri, Aug 21, 2009 at 3:04 PM, Evan Weaver<[email protected]> wrote: > No...I'm talking about column-oriented schemas in the BigTable sense. > It's unrelated to Cassandra's "columns". > > When a business object spans multiple column families, it can be > considered "column-oriented" because same fields are stored physically > close on disk despite being from different keys. It's similar to a > projection in a relational column store. > > Evan > > On Fri, Aug 21, 2009 at 2:49 PM, Sandeep Tata<[email protected]> wrote: >> 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. >> >> I'm not sure I understand the distinction you're drawing between >> row-oriented modeling and column-oriented modeling. >> Are you talking about row-oriented modeling as placing entire objects >> in a column (today's nomenclature) and treating a cassandra column >> like a database row? >> >> Sandeep >> > > > > -- > Evan Weaver >
