I can think of a fourth case: too many updates / second on a single table for a single master. Of course you can shard your sql servers, but then you loose so much of the power of sql joins, and queries will have to run across all servers etc etc. That one is probably the killer app for me when it comes to distributed masterless systems.
//Martin
On Nov 2, 2009 5:34 AM, "David Timothy Strauss" <da...@fourkitchens.com> wrote:
#2 is the main one for me. Consolidating and indexing (via denormalizing) data is complex, error-prone, and inefficient in SQL systems.
----- "Johannes Ernst" <jernst+google.com@netmesh.us> wrote: > Question to everybody in order to ...
David Strauss
| da...@fourkitchens.com
| +1 512 577 5827 [mobile]
Four Kitchens
| http://fourkitchens.com
| +1 512 454 6659 [office]
| +1 512 870 8453 [direct]
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are sub...
I'm adding one that might be specific to CouchDB, but it's a good one
(IMHO) so others might follow suit (some are already, to be fair :)
Easy of use: You shouldn't need a PhD in computer science to store
your data. Sure, a lot of us hacked our way into SQL (myself included)
but it took quite some time to figure out all the kinks, and then
some. Nonrelational databases have the great chance of letting the
developer "just store data" and concentrate on what they are best at:
Developing applications that rock their users' or customers' worlds.
Cheers
Jan
--
I will agree that is very true. Why do I need a schema, and have the
need to define a table just to store data.
Chaz
>
>
> On Mon, Nov 2, 2009 at 12:55 PM, <eprpa...@gmail.com> wrote:
>
> I will agree that is very true. Why do I need a schema, and have the
> need to define a table just to store data.
>
> Chaz
>
>
> For the same reasons you need classes, just to instantiate objects ;-)
Only in class-based OOP systems (cf http://en.wikipedia.org/wiki/Prototype-based_programming
).
Personally, prototypical inheritance works a lot like my brain and I
have a harder time getting class-based OO right.
I believe it is important to understand that type != structure. A
business card is a business card, whether it lists a fax number or
not. My business card doesn't say `fax = NULL`, yet it is a valid
instance of the type business card just like any business card that
lists a fax number. Coming from a Java & RDBMS background, type and
structure are very much the same. I find it liberating to not have the
two mangled together by my tools.
> At least changing a relational schema is a well-documented
> procedure. After 5 years of production, your old records were
> forcefully refactored to fit into all successive schema changes.
Migration tools don't really care if the storage is fixed or flexible.
A tool can migrate old records to a new schemeless design just as good.
> With unstructured storage, my guess is that the *code* needs to know
> how to map any record (old or new, whatever the contents) to the
> current core domain.
Your views will already have something like:
if(model.faxnumber != NULL) {
// see how bad my code is :D
display_fax_no(model.faxnumber);
}
This doesn't change in when switching to schemaless designs.
--
Thanks for bringing up these points. They force us to think harder how
to present why NoSQL databases can be a good idea.
Cheers
Jan
--
Migration tools don't really care if the storage is fixed or flexible.
A tool can migrate old records to a new schemeless design just as good.
Your views will already have something like:
if(model.faxnumber != NULL) {
// see how bad my code is :D
display_fax_no(model.faxnumber);
}
This doesn't change in when switching to schemaless designs.
On 2 Nov 2009, at 17:44, Johannes Ernst wrote:There is the very old (in language design) controversy about strongvs. weak typing and how beneficial or evil it might be.
The data on the web is messy and in no way fits a schema.
*headshot* :D
> The data on the web is messy and in no way fits a schema.
>
> *headshot* :D
OK, it's time for someone to put their foot down regarding schema. :-) The absence of schema has nothing to do with any technical advantages mentioned on this thread (or even list).
It just happens that most current nosql systems lack schema support. That's something we should lament, not celebrate. People have been using "schema" like a dirty word, an embodiment of all that is evil about the rigid, flat, and over-simplified tuple layout in many RDBMS tools, but schema is not *that* anymore than data storage is *SQL*.
A schema is simply an ontology, a way to structure data and define what's valid and what's not. Whether or not the data store understands the ontology, the application must. What the data store cannot guarantee, the application must itself validate. Worse, without schema support, the system degrades from structure guarantees about *every* item in the store to the application merely being able to validate *specific* items. Schema enforcement is a gatekeeper of validity, an especially important role when data stores are shared or applications are buggy.
A schema-aware data store provides many benefits to the application(s) using it, and I loathe to think that the nosql world will brand itself as anti-schema. It's OK for us to argue that strong schema support is less important than other data storage innovations being pursued in the nosql world, but we should not pretend its absence is good.
We should focus our efforts on schema models that make application development faster, more pleasant, and more reliable.
More of my schema ranting here:
http://fourkitchens.com/blog/2009/07/05/how-schema-got-bad-name
> Personally I think this is an orthogonal discussion: one can use a SQL
> database to store uninterpreted blobs, and one can us a strong type
> system even with a simple key-value store -- enforcement rules left as
> exercise for the programmer given the state of most projects today,
> but I'd bet more strongly typed system will show up in response to
> market demand from those who like strong type systems.
It's not really orthogonal. Many nosql systems use eventual-consistency models. Presence or absence of a schema (one understood by the data store) directly affects methods available for conflict resolution. Systems like CouchDB need also expect valid JSON with certain values populated in the resultant data structure (for, say, calculating views).
Our capabilities quickly hit a limit when we assume the values for key/value pairs are opaque to the data store.