Cassandra has always enforced the tiniest bit of schema. You basically define how you want your columns and subcolumns to be sorted within column families. You also name the column families and keyspaces. That's all though.
The part that is changing is that the keyspaces and column families will no longer be defined statically at runtime. [column families | keyspaces] may be [added | dropped] on a live cluster. Think of it as [CREATE|DROP|ALTER] TABLE for Cassandra. Gary. On Thu, May 13, 2010 at 14:48, Steve Lihn <stevel...@gmail.com> wrote: > What is changing? A more flexible schema or no need to restart (some kind of > hot-reboot)? > > Mongo guys claims that Mongo's advantage is a schema-less design. Basically > you can have any data structure you want and you can change them anyway you > want. This is done in the name of "flexibility", but I am not sure this is a > good practice. People argued for years that perl is bad because it is > typeless and java is strong typed and is better. Now the java community is > developing a database like Mongo that is schema-less. How does this > complements the strong-type argument? > > The less requirement is put on database schema design, the more burden is > put on the application to maintain data integrity. Why is this a good trend? > Can someone kindly explain? > > Steve > > > > On Thu, May 13, 2010 at 1:22 PM, Vijay <vijay2...@gmail.com> wrote: >> >> "Cassandra requires the schema to be defined before the database starts, >> MongoDB can have any schema at run-time just like a normal database." >> This is changing in 0.7 >> Regards, >> </VJ> >> >
