I guess I'd suggest dropping the "movement" rhetoric unless you are truly promoting non-relational databases as the be-all end-all solution for object persistence for all applications and use cases.
Most advocates of technologies like Tokyo Cabinet/Tyrant, Mongo, CouchDB, etc - don't seem to argue this, instead taking a much more responsible approach of suggesting organizations whose needs are best suited by non-RDBMSs check them out, rather than porting everything over whole-hog.
I suppose what I'm suggesting is that the "movement" frame doesn't match the mindset of most proponents of the paradigm. There's nothing political about it - it's just another (very awesome) technology to consider for certain cases.
Not only is 'movement' needlessly pompous (it's dangerously close to also having a 'manifesto'), NoSQL is uninformative - the negation can apply to a lot of things including key-value stores, LINQ, post-it notes stuck to my monitor, etc.
I dont agree. A movement doesn't have to be fundamentalistic. It doesn't have to propose that SQL is wrong in every case, only that SQL needn't be the first thing that comes to mind when you need to persist data, or the only thing.
The various NoSQL-solutions are quite different in nature, the only thing that really brings them together is that they're not SQL, and instead of each of them doing their own awareness raising campaigns, they probably do well to gang up. I don't even think they should change the name, it's not until now when they've created the NoSQL-umbrella that they're really getting some well-deserved attention.
There are plenty of solutions out there, pick the best one, or whichever one you just plain like more. And that might very well be SQL. Just don't pick SQL simply because that's the only solution you even know about. I think that's a message worth spreading.
At least in US presidential elections, more people vote against a candidate than for a candidate. They justify it by saying say "I'm voting for the lesser of the two evils", or "I don't particularly agree with everything my candidate stands for, but I sure hate the other guy". Examples in software also abound:
I don't see it happening because you don't change names once they've already been picked up by a community (well, you can but it's real difficult). Take AJAX.. that was just a coined name for a bunch of already existing technologies, but it stuck and it'd be next to impossible to change now (unless the whole concept were usurped).
How about the "more details required" conference? I like the subject matter and speakers list, but you have a rather "open" schedule. I'm on the fence at this point: I wouldn't mind an excuse to visit friends in Atlanta, but I feel like my money is buying steadicat's awesome website design.
Focusing on "SQL" being a problem is misguided. The amount of SQL knowledge needed to achieve basic CRUD/REST behavior takes about an hour to learn. More advanced SQL takes much longer but most of these new DBs don't allow for queries that complex or would not perform well if you tried.
I'm using mongodb for a new app at the moment. Here are some of the reasons I chose it:
1 - schema-less. I like having postgresql as my backstop for data constraints. It has saved me many times to have a locked down schema that will refuse to corrupt when my app code gets sloppy. That said, during the dev process, its nice at times to avoid thinking through these constraints and getting straight to persisting objects ad-hoc.
2 - fast enough. I have a few features that will creep into the area of "I might need memcached". I'm betting mongodb will be "fast enough" to give me one object repo for my entire app and I can avoid the headaches of writing cache management code.
3 - good enough. Having step 2, fast-enough, means I may have to give up some ACID. I don't need an ACID guarantee for this app. If I did, I would go back to step 2 and rethink writing all that cache management code as I'd stick with postgresql. I do need durability relative to my daily backup. If the tradeoff is 5 or 7 9s (postgres) for a system that is 3 9s (mongodb), and a restore from a dbdump always works, then 3 9s reliability is ok with me. Note: I have no meaningful data on mongodb reliability other than "others are using it for more demanding projects than mine and have good things to say".
4 - more than just simple key/value. I needed to be able to retrieve parts of objects, not just the entire value for a key.
5 - Simplify my app code. Sure, ORMs all well-refined: simple stuff is simple, complex stuff is possible. But it takes a heap of code. With ORM frameworks, I constantly monitor the SQL being output to the log to ensure the framework crafted my SQL properly. Now that I'm using mongodb, my app code's "models" are just thin wrappers around a ruby Hash and simple queries go straight to the mongo ruby drver API. More complex queries get written by me and sit as their only little methods on my model objects. Sure, there is a ruby framework and evolving DSL for mongo, but I want to get away from these added layers.
Notice that the syntax or structure of the db's query language did no crack my requirements list? In fact, mongo has what I would consider some inconsistencies in its query language (if you could even call it a language).
[+] [-] cscotta|16 years ago|reply
Most advocates of technologies like Tokyo Cabinet/Tyrant, Mongo, CouchDB, etc - don't seem to argue this, instead taking a much more responsible approach of suggesting organizations whose needs are best suited by non-RDBMSs check them out, rather than porting everything over whole-hog.
I suppose what I'm suggesting is that the "movement" frame doesn't match the mindset of most proponents of the paradigm. There's nothing political about it - it's just another (very awesome) technology to consider for certain cases.
[+] [-] pvg|16 years ago|reply
[+] [-] tjogin|16 years ago|reply
The various NoSQL-solutions are quite different in nature, the only thing that really brings them together is that they're not SQL, and instead of each of them doing their own awareness raising campaigns, they probably do well to gang up. I don't even think they should change the name, it's not until now when they've created the NoSQL-umbrella that they're really getting some well-deserved attention.
There are plenty of solutions out there, pick the best one, or whichever one you just plain like more. And that might very well be SQL. Just don't pick SQL simply because that's the only solution you even know about. I think that's a message worth spreading.
[+] [-] jawngee|16 years ago|reply
And the NoSQL is needlessly negative as well.
[+] [-] ynniv|16 years ago|reply
[+] [-] rwolf|16 years ago|reply
[+] [-] marcusbooster|16 years ago|reply
[+] [-] jazzychad|16 years ago|reply
[+] [-] jwecker|16 years ago|reply
Neo something...
ModernDB
KV something...
Fast data...
East of SQL
Sorry. It would probably help if you laid out your constraints (need it short? need the word 'noSQL'? need an available URL? ...)
"I think maybe my creativity broke. Let's see, uh... meatloaf. Yup, it's broke alright." - Strongbad
[+] [-] blasdel|16 years ago|reply
[+] [-] edw519|16 years ago|reply
"We have not achieved it; therefore, it cannot be achieved."
How about the "NoSQL Movement". No Scientifically Qualified Logic.
[+] [-] gtuhl|16 years ago|reply
[+] [-] JoelSutherland|16 years ago|reply
I would call it something like the Alternative Database Movement.
[+] [-] andreyf|16 years ago|reply
http://gettingreal.37signals.com/ch02_Have_an_Enemy.php
http://www.codinghorror.com/blog/archives/001246.html
[+] [-] rwolf|16 years ago|reply
[+] [-] petercooper|16 years ago|reply
[+] [-] gaius|16 years ago|reply
[+] [-] voodootikigod|16 years ago|reply
[+] [-] sbecker|16 years ago|reply
[+] [-] ynniv|16 years ago|reply
[+] [-] figital|16 years ago|reply
Perhaps "#noIndexes" or "#noRightOuterJoins"
[+] [-] discojesus|16 years ago|reply
[+] [-] sp332|16 years ago|reply
[+] [-] jhancock|16 years ago|reply
I'm using mongodb for a new app at the moment. Here are some of the reasons I chose it:
1 - schema-less. I like having postgresql as my backstop for data constraints. It has saved me many times to have a locked down schema that will refuse to corrupt when my app code gets sloppy. That said, during the dev process, its nice at times to avoid thinking through these constraints and getting straight to persisting objects ad-hoc.
2 - fast enough. I have a few features that will creep into the area of "I might need memcached". I'm betting mongodb will be "fast enough" to give me one object repo for my entire app and I can avoid the headaches of writing cache management code.
3 - good enough. Having step 2, fast-enough, means I may have to give up some ACID. I don't need an ACID guarantee for this app. If I did, I would go back to step 2 and rethink writing all that cache management code as I'd stick with postgresql. I do need durability relative to my daily backup. If the tradeoff is 5 or 7 9s (postgres) for a system that is 3 9s (mongodb), and a restore from a dbdump always works, then 3 9s reliability is ok with me. Note: I have no meaningful data on mongodb reliability other than "others are using it for more demanding projects than mine and have good things to say".
4 - more than just simple key/value. I needed to be able to retrieve parts of objects, not just the entire value for a key.
5 - Simplify my app code. Sure, ORMs all well-refined: simple stuff is simple, complex stuff is possible. But it takes a heap of code. With ORM frameworks, I constantly monitor the SQL being output to the log to ensure the framework crafted my SQL properly. Now that I'm using mongodb, my app code's "models" are just thin wrappers around a ruby Hash and simple queries go straight to the mongo ruby drver API. More complex queries get written by me and sit as their only little methods on my model objects. Sure, there is a ruby framework and evolving DSL for mongo, but I want to get away from these added layers.
Notice that the syntax or structure of the db's query language did no crack my requirements list? In fact, mongo has what I would consider some inconsistencies in its query language (if you could even call it a language).
So here are some suggestions for a better name:
* - alt.db
* - SchemaFree
* - less_ACID
* - next-gen object stores
* - hybrid db models
[+] [-] discojesus|16 years ago|reply
or maybe the Lewinsky Club ("I'm going to say this again: we DO NOT have relations.")
http://www.instantrimshot.com
[+] [-] stevedavis|16 years ago|reply
[+] [-] prb|16 years ago|reply
[+] [-] obecalp|16 years ago|reply
[+] [-] unknown|16 years ago|reply
[deleted]