Hot answers tagged

278

You can query data in a database (ask it questions). You can look up data from a database relatively rapidly. You can relate data from two different tables together using JOINs. You can create meaningful reports from data in a database. Your data has a built-in structure to it. Information of a given type is always stored only once. Databases are ACID. ...


200

Whilst I agree with everything Robert said, he didn't tell you when you should use a database as opposed to just saving the data to disk. So take this in addition to what Robert said about scalability, reliability, fault tolerance, etc. For when to use a RDBMS, here are some points to consider: You have relational data, i.e. you have a customer who ...


169

It's not about NoSQL vs SQL, it's about BASE vs ACID. Scalable has to be broken down into its constituents: Read scaling = handle higher volumes of read operations Write scaling = handle higher volumes of write operations ACID-compliant databases (like traditional RDBMS's) can scale reads. They are not inherently less efficient than NoSQL databases ...


75

noSQL databases give up a massive amount of functionality that a SQL database gives you by it's very nature. Things like automatic enforcement of referential integrity, transactions, etc. These are all things that are very handy to have for some problems, and which require some interesting techniques to scale outside of a single server (think about what ...


74

When he reviewed the database schema he stated that all foreign keys and other such constraints should be removed as this is business logic and should be applied within the business layer. Then he's an idiot, and some excerpt from your codebase is likely to end up on The Daily WTF someday. You're absolutely right that his approach doesn't make sense, and ...


62

There are many NoSQL solutions around, each one with its own strengths and weaknesses, so the following must be taken with a grain of salt. But essentially, what many NoSQL databases do is rely on denormalization and try to optimize for the denormalized case. For instance, say you are reading a blog post together with its comments in a document-oriented ...


55

One thing that no one seems to have mentioned is indexing of records. Your approach is fine at the moment, and I assume that you have a very small data set and very few people accessing it. As you get more complex, you're actually creating a database. Whatever you want to call it, a database is just a set of records stored to disk. Whether you're creating ...


40

Generally speaking, if your workflow is a perfect match for relational database queries, you'll find relational databases to be the most efficient approach. Its kind of tautological, but its true. The claim that many NoSQL advocates would make is that many workflows were actually massaged into a relational form, and would have been more effective before ...


40

While I agree with your premise that NoSQL is not a panacea for all database woes, I think you misunderstand one key point. In NoSQL database you have only one criterion you can search for effectively - the key. This is clearly not true. For example MongoDB supports indices. (from https://docs.mongodb.org/v3.0/core/indexes-introduction/) Indexes ...


27

The thing you are missing about NoSQL is that NoSQl cannot be compared to SQL in any way. NoSQL is name of all persistence technologies that are not SQL. Document DBs, Key-Value DBs, Event DBs are all NoSQL. They are all different in almost all aspects, be it structure of saved data, querying, performance and available tools. So if someone asks you such ...


21

Appropriate approach for NoSQL database design is a DDD (Domain Driven Design ). For some people who used to design RDBMS, NoSql looks like Sql anti-patterns and it make more sense when considered in a scope of a DDD. Depending on usage of addresses, you may define it as a value object inside your rental history model/entity. Here you are some references ...


20

Sorry to add another answer but none of the answers here are very satisfactory. This answer is specific to MongoDB (as opposed to the vast array of other data storage options out there which are not relational databases). Pros: MongoDB has a lower latency per query & spends less CPU time per query because it is doing a lot less work (e.g. no joins, ...


19

Just because your NoSql database doesn't have a schema in a traditional sense doesn't mean there isn't a logical schema you need to deal with as it changes. In the case of a typical app using MongoDb, most likely your code expects certain fields of the json object to behave in certain ways. If you change the behavior, it follows you might want to update the ...


19

But is that really a big problem when doing upgrades? It can be. Some organizations are -- well -- disorganized, and do a very bad job of schema migration. "Migration Weekend". Stop the servers. Back up and export all the data. Build the new schema (often by modifying the existing schema). Reload data or attempt to restructure in place. "Continuous ...


19

General Uses If you have data structures that are not clearly defined at the time when you make the system. I tend to keep user settings in nosql, for example. Another example was a system where the users needed to be able to add fields at runtime - very painful in an RDBMS and a breeze in NoSQL. If your model structure is largely centered around one or few ...


17

TL;DR Normalization in RDBMS allows you to leverage the strengths of the relational paradigm. Denormalization in NoSQL allows you to leverage the strengths of the NoSQL paradigm. Long answer RDBMS are great because they let you model unique structured entities (mutable or not) and their relationships with one another. This means it's very easy to work ...


16

'NoSQL' (or more precisely: non-relational) databases give up some features of the traditional databases for speed, but more importantly for horizontal scalability. The missing features depend on the concrete product, in general full ACID properties or even join operations are not supported. That is the price for the increased performance.


16

No, that's not it at all. What you describe is gaining an advantage either by caching (having computed the answer before the request arrived) or by parallelization (tasking more than one node with the computation of a big sum). Neither is necessarily exclusive to 'NoSQL' data bases. (I use scare quotes because what people call 'NoSQL' these days is mostly ...


16

NoSQL is a rather vague term, since it basically covers all database systems which are not relational. What you describe is a key-value store, which is a kind of database where a blob of data is stored under a key, and can be quickly looked up if you know the key. These databases are blazingly fast if you know the exact key, but as you say yourself, if you ...


15

The main reason for choosing a NoSQL database the last years have been Availability. For companies like Amazon, Google and Facebook an hour of downtime or so isn't acceptable. To achieve high availability you need to reduce single-point-of-failure, that means you need to use a distributed system with multiple computers in case a computer crashes, the service ...


14

Use the right tool for a particular job. By asking this, it's clear you don't know when NoSQL is appropriate for data storage. A lot of people are using NoSQL just because it is the "thing of the moment". Usually NoSQL databases have no schema and should be used when the data is better represented by its model. You should not use a NoSQL database to store ...


14

When you have simple data, like a list of things as you describe in the comments of your question, then an SQL database won't give you much. A lot of people still use them, because they know their data can get more complicated over time, and there are a lot of libraries that make working with database trivial. But even with a simple list that you load, hold ...


14

Basically: If you can represent your data in a form of a bunch of documents, MongoDB could be a good choice. If you would rather imagine your data as a bunch of interconnected tables, MongoDB may not be a good choice. Here are two examples which I find illustrative: A few years ago, I created a blog engine. Its purpose is to host blog articles, and for ...


13

You've run into a problem that many have before you...a database optimized for reading is seldom good for write efficiency and vice versa. One approach that has evolved from this read-write impediment is CQRS (Command Query Responsibility Segregation). Despite Wikipedia linking the two together CQRS and CQS are technically different. CQS just demands that a ...


13

First, there are clearly defined use cases for using NoSQL over a traditionnal RDBMS. Make sure your system meets one or more of these criteria before jumping into NoSQL, or else you could run into problems. This youtube video has been a real eye-opener for me. It is about MongoDB and data modeling. You can read more about MongoDB on their website.


13

How big a data? There are two significant thresholds: whole data fits in the RAM whole index data fits in the RAM With fast SSDs the first threshold became bit less of an issue, unless you have crazy high traffic. ACIDity One of the problem with scaling RDBMSes is that by design they are ACID, which means transactions and row level locks (or even table ...


13

I don't think that the size of data is the only factor. "Data model" is also a very important part. E-Commerce catalog pages (Solr, ElasticSearch), web analytics data (Riak, Cassandra), stock prices (Redis), relationships connections in Social Networks (Neo4J, FleetDB) are just some examples when a NoSQL solution really shines. IMHO, data model has more ...


13

I think you'd definitely like to look at this paper by Erik Meijer & Gavin Bierman, titled "Contrary to popular belief, SQL and NoSQL are really just two sides of the same coin". In short, it claims that mathematically speaking both approaches base on the same theory, but with some differences. Couple of interesting differences are, from my opinion, ...


13

Please consider this as an alternative. The previous two examples will both require that you make changes to the schema as the application's scope grows in addition the "custom_column" solution is difficult to extend and maintain. Eventually you'll end up with Custom_510 and then just imagine how awful this table will be to work with. First let's use your ...


Only top voted, non community-wiki answers of a minimum length are eligible