Hot answers tagged

216

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


160

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


72

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


54

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


44

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


38

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


34

There are many NoSQL solutions around, each one with its own strenghts 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 omptimize for the denormalized case. For instance, say you are reading a blog post together with its comments in a document-oriented ...


33

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


29

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


24

NoSQL is more evolutionary than revolutionary. It essentially combines the existing ideas of "external database storage" with "using familiar data structures, not relational tables." There are more types of databases than relational, for example hierarchical databases. While archaic by today's standards, it meshed really well with the data structures of its ...


15

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


14

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


13

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


13

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


13

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


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


12

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


12

Just because your NoSql database doesn't have a schema in a traditional sense doesn't mean there is 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 ...


12

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


11

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


11

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.


11

I see a lot of answers focus on the problem of concurrency and reliability. Databases provide other benefits beside concurrency, reliability and performance. They allow to not to bother how bytes and chars are represented in the memory. In other words, databases allow programmer to focus himself on "what" rather than "how". One of the answers mentions ...


11

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


10

The decision of whether to use relational DB or non-relational (document/OO/graph) database should not be based on the representation of the data (JSON/BSON/XML/...), but on the operations you intend to preform on the data. If you have a strict schema, and you need to execute SQL queries - You should use relational DB. Otherwise, you may consider other ...


10

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


10

We may not be able to help you until you tell us what you intend to do with the app. Relational databases are good for certain things, and NoSQL databases are good for others. As someone once said to me here on SO: the relational part of a relational DB is far more optimized than some other parts It means you can use a relational database also if ...


10

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


10

Keep in mind, once you accumulate enough data, your simple home-grown approach will be very slow when it comes to retrieval unless you then implement some sort of indexing system. So if thats a potential issue, I'd stick with using a dbms. In addition to using a NoSQL server, you can also use an SQL database to store key pairs. There's nothing inherent ...


10

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



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