5 ms·

One could argue that SQL is a premature optimization as well if all you need is a key/value store or a document store. Using SQL just in case you may need ad-h

One could argue that SQL is a premature optimization as well if all you need is a key/value store or a document store. Using SQL just in case you may need ad-hoc queries could be as harmful as using NoSQL just because you may need to scale. Each application is different and you need to pick the appropriate tools.

badclient 15y ago
And that would be a perfectly fine argument! Though I am not aware of anything significant that can be built without a relational db. Even the simplest college assignments about building an address book involve querying and referencing primary keys across tables.
- icebraining 15y ago
  You can do queries and reference other documents many NoSQL databases; look at the documentation for GAE's datastore: http://code.google.com/appengine/docs/java/datastore/queries.html#Fetching_Results http://code.google.com/appengine/docs/java/datastore/queries... Or for MongoDB: http://www.mongodb.org/display/DOCS/Advanced+Queries http://www.mongodb.org/display/DOCS/Advanced+Queries
  - dreamdu5t 15y ago
    That is relational though. In those cases, Redis and MongoDB must create some kind of key reference table like MySQL would.
    - icebraining 15y ago
      It depends on what do you mean by relational. I mean, even the simplest key-value store has to have keys, so if you store the key of another record/document, you have a "relation." But you can't set constraints that enforce such relations, which is the whole point of the relational model.
- ericmoritz 15y ago
  An address book is a fine example for a document database or key value store. You'd just need two buckets or collections in the key value store. user_to_contact_sets -> keyed on user's key contacts -> keyed on a contact id For searching I'd use a real search engine and index the contact data as it is stored and deleted. The beauty of using a schema-free KVS you can have a much more flexible contact document that can have embedded one-to-many objects that would require a number of extra tables in SQL for data that will only ever be associated to a single contact record. Here's an example of a hypothetical KVS storing contact data: // API: db.store = function(bucket, key, data) { ... } db.fetch = function(bucket, key) { ... } search_engine.index = function(key, document) { ... } // Store a Contact record: var contact = {"id": "eric-moritz", // lexicographically ordered key "name": "Eric Moritz", "emails": [ {"type": "personal", "value": "eric@example.com"}, {"type": "work", "value": "workin@example.com"}], "addresses": [ {"type": "home": "address1": "111 A ST", "city": "somewheresville", "state": "somestate", "postal-code": "90210"}, {"type": "work": "address1": "111 B ST", "city": "somewhereelseville", "state": "somestate", "postal-code": "90210"}], "phone-numbers": [ {"type": "mobile", "value": "555-1212"}, {"type": "work", "value": "555-2323"}] } // Fetch the user's contact set var contact_set = db.fetch("contact_sets", user_id); // If this contact is not already indexed, add it and store the set if(contact_set.indexOf(contact['id']) < 0) { contact_set.push(contact['id']); db.store("contact_sets", user_id, contact_set.sort()); } // Store the contact into the contacts bucket var contact_key = user_id + ":" + contact['id']; db.store("contacts", contact_key, contact); // Index the document into the search engine search_engine.index(contact_key, contact)
dreamdu5t 15y ago
That would be a fine argument, except that you almost always need more than a key/value store. Even a basic chat software, you'll want to relate users to messages. Even session management.

badclient 15y ago

And that would be a perfectly fine argument! Though I am not aware of anything significant that can be built without a relational db. Even the simplest college assignments about building an address book involve querying and referencing primary keys across tables.

icebraining 15y ago
You can do queries and reference other documents many NoSQL databases; look at the documentation for GAE's datastore: http://code.google.com/appengine/docs/java/datastore/queries.html#Fetching_Results http://code.google.com/appengine/docs/java/datastore/queries... Or for MongoDB: http://www.mongodb.org/display/DOCS/Advanced+Queries http://www.mongodb.org/display/DOCS/Advanced+Queries
- dreamdu5t 15y ago
  That is relational though. In those cases, Redis and MongoDB must create some kind of key reference table like MySQL would.
  - icebraining 15y ago
    It depends on what do you mean by relational. I mean, even the simplest key-value store has to have keys, so if you store the key of another record/document, you have a "relation." But you can't set constraints that enforce such relations, which is the whole point of the relational model.
ericmoritz 15y ago
An address book is a fine example for a document database or key value store. You'd just need two buckets or collections in the key value store. user_to_contact_sets -> keyed on user's key contacts -> keyed on a contact id For searching I'd use a real search engine and index the contact data as it is stored and deleted. The beauty of using a schema-free KVS you can have a much more flexible contact document that can have embedded one-to-many objects that would require a number of extra tables in SQL for data that will only ever be associated to a single contact record. Here's an example of a hypothetical KVS storing contact data: // API: db.store = function(bucket, key, data) { ... } db.fetch = function(bucket, key) { ... } search_engine.index = function(key, document) { ... } // Store a Contact record: var contact = {"id": "eric-moritz", // lexicographically ordered key "name": "Eric Moritz", "emails": [ {"type": "personal", "value": "eric@example.com"}, {"type": "work", "value": "workin@example.com"}], "addresses": [ {"type": "home": "address1": "111 A ST", "city": "somewheresville", "state": "somestate", "postal-code": "90210"}, {"type": "work": "address1": "111 B ST", "city": "somewhereelseville", "state": "somestate", "postal-code": "90210"}], "phone-numbers": [ {"type": "mobile", "value": "555-1212"}, {"type": "work", "value": "555-2323"}] } // Fetch the user's contact set var contact_set = db.fetch("contact_sets", user_id); // If this contact is not already indexed, add it and store the set if(contact_set.indexOf(contact['id']) < 0) { contact_set.push(contact['id']); db.store("contact_sets", user_id, contact_set.sort()); } // Store the contact into the contacts bucket var contact_key = user_id + ":" + contact['id']; db.store("contacts", contact_key, contact); // Index the document into the search engine search_engine.index(contact_key, contact)

dreamdu5t 15y ago

That would be a fine argument, except that you almost always need more than a key/value store. Even a basic chat software, you'll want to relate users to messages. Even session management.