Linked by MOS6510 on Fri 2nd Aug 2013 18:06 UTC
Let’s say you’ve decided to set up a website or an application. You'll obviously need something to manage the data. Yes, that's right, a database. So, what is it going to be? MySQL, MS-SQL, Oracle or PostgreSQL? After all, nothing can be as amazing as a good old RDBMS that employs SQL to manage the data.

Well, allow me to introduce to you an entirely unique and unconventional Database model - NoSQL.

Thread beginning with comment 568737
To read all comments associated with this story, please click here.
Comment by Kroc
by Kroc on Fri 2nd Aug 2013 19:22 UTC
Member since:

Assess the tools available to you and use the right one for the job. If you're comfortable with SQL then that's no excuse to ignore NoSQL methods.

IMO SQL databases are heavily overused on the web. If you don't need to do highly selective data cherry-picking (such as filtering of a result set), or mashing of two sets of data together (analytics), then often a flat data store is simpler, faster and more reliable. For the web, you don't need an SQL database to serve static content, and where you need to index and search content you have offline systems like Syphinx that give you a database for searching but you can keep the fast static caches for the content. (i.e. use flat files for what they're good for and SQL for what it's good for)

Because I didn't like the downsides of SQL databases for web content (portability / maintenance / security / setup&config time) I created a forum system that has no database, just RSS feeds -- each discussion thread is itself an RSS feed. This means that setup is a matter of seconds (unzip and run) and the data is portable, easy to parse, transform, manage, convert and generally process without the need of specialised / my software. Google for NoNonsense Forum should you be interested.Google for NoNonsense Forum should you be interested.

The benefits for my use case made NoSQL the right choice, but I wouldn't think twice about using an SQL database if a project needed those kind of requirements. My point is: learn what's possible with each approach (benefits / drawbacks) and use each to its full potential, and don't be afraid of mixing methods!

Reply Score: 5

RE: Comment by Kroc
by Lennie on Fri 2nd Aug 2013 22:11 in reply to "Comment by Kroc"
Lennie Member since:

Many now use a version control system to store their versioned flat files.

Some Wiki implementations for example store and retrieve directly from git.

Reply Parent Score: 2

RE: Comment by Kroc
by henderson101 on Fri 2nd Aug 2013 22:57 in reply to "Comment by Kroc"
henderson101 Member since:

I've done it as a traditional database, a key/value store and an ORM, where I really didn't care what the DB looked like. Honestly, the best approach is to either ORM the dataset (I used Entity Framework code first in a number of projects, doing so, the database structure became competely opaque) or use tables for static data and K/V for dynamic data. The biggest issue with K/V is reporting on the data. If a reporting solution is critical (e.g. Sales, stats etc) then K/V really falls down. Pivoting giant chunks of data is no real fun. Neither is field bloat in traditional tabular databases, so the happy middle ground works well.

Reply Parent Score: 3