

Help pick a better name for NoSQL Movement at NoSQL East Conference - voodootikigod
http://www.nosqleast.com

======
cscotta
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.

~~~
pvg
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.

~~~
silentbicycle
In its vagueness it suggests knee-jerk criticism of RDBMSs, rather than any
major advantage the alternatives have.

I went to a presentation about CouchDB recently, and afterward asked a couple
questions about distribution, how views work, transactions, comparing its
design and performance to RDBMSs, etc. It was immediately clear that the
speaker didn't really understand the relational model at all (and he kept
calling SQL "MySQL"). He couldn't answer several of my questions, but pointed
out several times that the technology behind CouchDB is "way sexy". Now, I
really like Postgres and SQLite, but I'm curious about the other systems
because I'm a bit of a database nerd, and I was hoping he could explain _what
problems they solve_ , beyond some handwavey assertions about scaling and
reassuring people with an aversion to SQL.

I'm not saying he's representative, but he comes to mind when I hear about a
noSQL movement. People whose sole understanding of RDBMSs seems to have come
from e.g. _PHP & MySQL For Dummies_, but keep hearing that SQL doesn't scale
and noSQL databases are "the new hotness". Talk about the _advantages_ of
those systems compared to RDBMSs! And if you can't talk about any _collective_
advantages they have, because they don't have much common ground (which is
quite possible), then trying to present them collectively is just going to be
confusing.

~~~
mseebach
> _PHP & MySQL For Dummies_

That may be a pretty big part of the explanation. Most of the apps build on
knowlegde rathered in that book, would probably benefit from being released
from the constraints of SQL (and on the level of a blog or forum app SQL _is_
more of a constraint than a benefit).

------
jwecker
Rational Database movement (long, but play on words - I like that it doesn't
imply anti-sql, but using rational choices when an RDBMS isn't necessary)

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
'Rational DB' would be perfect if the makers of ClearCase hadn't permanently
poisoned that word

------
rwolf
I love the CLI for this website. I know it's silly, but it warms my heart.

~~~
marcusbooster
Nice. I'm enjoying the tab-completion as well.

------
jhancock
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).

So here are some suggestions for a better name:

* - alt.db

* - SchemaFree

* - less_ACID

* - next-gen object stores

* - hybrid db models

------
JoelSutherland
It doesn't make sense to frame it negatively. You don't (often) see fans going
to bars to root _against_ a team.

I would call it something like the Alternative Database Movement.

~~~
andreyf
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:

<http://gettingreal.37signals.com/ch02_Have_an_Enemy.php>

<http://www.codinghorror.com/blog/archives/001246.html>

~~~
philwelch
I think we've witnessed at least one recent presidential election where a
large number of people _actually liked_ one of the candidates, and as a
result, turnout and share of the vote were both much higher than other recent
years. Being the lesser of two evils is only a viable strategy when both sides
pursue it.

The reason it seems to work in politics is because it's hard for politicians
to be perceived as principled and noble.

------
petercooper
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).

------
gaius
The NoCLUE Movement.

~~~
voodootikigod
hey, way to be helpful. thanks!

------
sbecker
Tower of Babel movement ;)

------
ynniv
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.

------
edw519
_The reasons for using these new systems are varied, but often involve scale
that relational solutions cannot achieve._

"We have not achieved it; therefore, it cannot be achieved."

How about the "NoSQL Movement". No Scientifically Qualified Logic.

~~~
gtuhl
While I think some of these new projects are great for certain tasks, this
sentiment resonates with me often when talking with nosql evangelists.

------
figital
Long overdue.

Perhaps "#noIndexes" or "#noRightOuterJoins"

------
discojesus
I dunno about a name, but how about this for a slogan - "You can sign up, but
don't ever JOIN."

------
discojesus
OK how about this for a name - "Data Without Borders"?

or maybe the Lewinsky Club ("I'm going to say this again: we DO NOT have
relations.")

<http://www.instantrimshot.com>

------
sp332
Database Admins Realizing There Be Other Databases (DARTBORD)?

------
stevedavis
Maybe explore "BASE" vs "ACID" (coined elsewhere)

------
prb
How about "dbNG" for next-generation database?

------
obecalp
PostSQL is better than NoSQL

~~~
timanglade
Dunno that is the case… Kinda implies it will replace SQL when in fact most
people involved realize it's meant to coexist with SQL. Plus, some of the non-
relational paradigms actually _pre_ date the relational paradigm.

