Tag Info

Hot answers tagged

206

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


151

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


65

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


41

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


28

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


26

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


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


22

I don't think so. Basically most of the NoSQL solutions seem to store key value pairs more or less. If you want to report on something, it is much easier to join a few tables together then to figure out how to string a whole bunch of key value pairs together. Also many of the products have their own API so the skills don't translate as well as SQL. ...


20

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


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


13

NoSQL puts the burden of managing your data directly upon the programmer to work with the information primitives whatever NoSQL database provides. Think of a relational database as a ready-to-use package of information management functions within its framework of storage and computation. Programming a NoSQL system is a lot like having the parts of a ...


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

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

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


12

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


11

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


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


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

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


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

Snowman's answer correctly describes how SQL and NoSQL differ in their data structures and how these are accessed. However, a probably even more important difference is their respective problem domain. NoSQL is not a successor of SQL. Rather, the various branches of NoSQL sacrifice some qualities of SQL in order to be better at others. The CAP theorem ...


9

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


9

We may not be able to help you till you don't tell us what you intend to do with the app. Relational databases are good at certain things, and NoSql are good at some 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 ...


9

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.


9

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


9

The answer to this was ANSI SQL. Although initial adoption was hard, especially for databases like Oracle, many of them now allow the ANSI standard. For example Oracle started allowing that format in 9i (see http://allthingsoracle.com/ansi-sql/) Also - PostgreSQL prides itself in standards compliance. Its SQL implementation strongly conforms to the ...


9

I would not use a database for this, but rather a full-text indexing engine. While database engines may include full-text indexing capabilities, they are generally less efficient than dedicated engines. This is also true for NoSQL databases. You may want to look at the following projects: Elastic Search (based on Lucene) Apache Solr (based on Lucene) ...


8

We had to give up on the relational model because the data we were getting had no simple, obvious, fixed, static schema. The users -- and the user stories -- did not have a fixed, static schema. We tried to impose a fixed, static, RDBMS schema, but it was a mistake. Each 3rd party data delivery (from customers and from vendors) was similar, but not ...



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