Hacker News new | ask | show | jobs
by bitdiffusion 5237 days ago
The notebook/note example is weak - in a nosql database you need to design your data structure appropriately to get the level of atomicity you require.

Storing an entire notebook in a single document would be the most obvious. I use postgres all the time and sql is great, but poo-pooing nosql because it wouldn't work with your relational structure is not the best idea. Also - I have found a hybrid between nosql (mongodb) and sql (postgres) is ideal - who says you need to use a single database?
3 comments
bni 5237 days ago
What about when you want to find all notes that was made a specific day last month (say for a report)?

Traverse all notebook documents and look at each notes date? Good luck with that.

link
artsrc 5237 days ago
Many nosql databases support queries. If you are using one of these then you are in a better place for features like that than you are with heavily shaded SQL.
link
tommyd 5237 days ago
If you were to use MongoDB, wouldn't this just be a case of adding an index to the field of the nested child document (i.e. the note within a notebook) you were interested in and then querying on it? e.g. db.notebooks.ensureIndex({"notes.date": 1});
link
morganpyne 5237 days ago
Well, taking a consistent snapshot for backups is easier when it's in a single source. I know there are ways around this (ZFS!) and not everyone needs synced backups to the millisecond but it can complicate backups (or more to the point - restores)
link
huggyface 5237 days ago
Storing an entire notebook in a single document would be the most obvious.

The cost of course being that a change to any note in a notebook yields a save of the entire document. Not a problem in simple cases, but that sort of mass-write-amplification can kill you (talk to Digg about that).

Also - I have found a hybrid between nosql (mongodb) and sql (postgres) is ideal - who says you need to use a single database?

Simplicity. Coherency. Maintainability. And on. Sure, it might make sense, but if you already have you toes in the "SQL" world, it is usually worthwhile to dunk your whole foot in. Many SQL products also offer the document functionality of MongoDB, for instance. SQL Server, as an example, lets you store XML documents to your hearts content, which you can index and intelligently query upon, etc. Your scheme is boundless, and on and on.

link