A relational database consists of pre-defined tables, where the data in table one is referred to by data in table two.
In a non-relational database the tables are not pre-defined, they just contain lots of key-pair values per record.
So it might be that a record contains the key “foo”, but that the others don’t. You can still do the equivalent of “select foo from table”, you just only get the records back with that key.
Personally I don’t like this, but others have a good use for it.
A non-relational database (like nosql) uses a storage structure that isn’t the tabular storage (rows and columns) system that relational databases do.
They are more purpose driven and are useful, when tailored, for a large scale system serving large amounts of data, but has difficulties in being queried in a generalized way.
Think of it as a building that might not have bedrooms and bathrooms like a traditional house, but it purposely constructed to store caustic chemicals so is useful for that purpose.
A relational database is a database that relies on (related) tables for data storage. Typically they’ll use some flavor of SQL (structured query language) for access.
Any database that doesn’t rely on a tabular structure is not relational (or, more commonly, NoSQL). There are [several different types](https://en.wikipedia.org/wiki/NoSQL#Types_and_examples) of NoSQL database, and which one is best depends on context.
I like to think. Non relational simply as a filing cabinet. All these records go in this drawer, these different records go in this drawer. It doesn’t matter that the drawer is next a drawer holding unrelated files as long as each drawer only contains files of its type. We would still know where to go look for each file.
Versus a relational which would be like this filing cabinet has several drawers and each drawer contains a reference to the other drawers that might make this file more interesting if needed.
Which kind?
There is the hierarchical database ([https://en.wikipedia.org/wiki/Hierarchical_database_model](https://en.wikipedia.org/wiki/Hierarchical_database_model)) where data is organized into a tree structure. Very fast for certain kinds of searching, but not particularly popular anymore.
There is the navigational database ([https://en.wikipedia.org/wiki/Navigational_database](https://en.wikipedia.org/wiki/Navigational_database)), which a hierarchical is arguably a type of.
These were mostly popular when computers were still super expensive. But as relatively cheap disks and processors became available they were supplanted by the relational database.
Going forward, as computers continue to get faster, you now have object databases ([https://en.wikipedia.org/wiki/Object_database](https://en.wikipedia.org/wiki/Object_database)), NoSQL ([https://en.wikipedia.org/wiki/NoSQL](https://en.wikipedia.org/wiki/NoSQL)), and probably others as well.
When we say ‘relational database’ we mean something specific and it involves something called ‘relational algebra’. This is a great way of storing data, it can get complicated but there is a reason we have been using relational databases for a lot of years and we will continue to use them for a lot of years. The genius responsible (and he is one) for this method of storing data is named Edgar Codd.
A non-relational database is literally any other database. Many will use what a lot of us would recognize as a JSON object or Python dictionary for when that might be a better way of storing data. Something like a MongoDB or something. Many will index using shards and the file system, which is different than how you index a relational database.
In a relational database we might have a table with columns “Name”, “Birthdate”, etc. it is essentially excel spreadsheet(s). A nonrelational database might have a key / value pair instead of a column head and row value. A key value pair will look like this;
Fruit:fruit_type:banana
Fruit:fruit_type:apple
If you were to query all fruit types you have to drill down the object to get to the values you want.
Depending on how deep the JSON object goes (so how many colons to get to your desired value) this is a crappy way of getting information. Or, it can be genius, it just depends on your application.
A database is nothing more than a way to store and retrieve data. The “relational” part of it has to do with how that data is organized. Some data organization has very strict rules, some have less strict rules.
Lets look at toy cars as an example. If you had a giant pile of hundreds of toy cars, and you wanted to organize them in such a way that they were easy to find, you could assign attributes about those cars to a model. How many doors, what color is the paint, what company made the car, etc. Then, once all the cars are organized, it becomes easy to ask a question like “I want a blue, 4-door, Hot Wheels car”. You know if one exists, if multiple exist, if none exist, etc because organizational structure forces you to have answers to all those questions for each car.
A relational database is a way to structure the relationship between the car and it’s attributes. You know that all cars have wheels, all cars have a manufacturer, and all cars have a paint color. All cars have all 3, and a car cannot exist without having all three. The attributes are strongly related object it is describing.
However, such a rigid structure has some downsides. For example, lets say one of your cars has a jetpack attached to it. How do you record that in our previous model? Do you add a 4th attribute that says “car has jetpack” and put “no” on every car except this one? You can. . . but it’s a lot of wasted data. So the alternative is to weaken the relationship between the “car” object and it’s attributes. In a non-relational database we can assign whatever attributes we want to “car”. So this car can have a color and a manufacturer, but no doors. This one can have doors and a jetpack, but no manufacturer. This one may just have a color and the date that you purchased it. There is still data describing each car, but the data-set describing each car are not “related” to each other. So if you ask “give me all blue cars”, you can still answer that question, but you just have to ignore all cars that do not have the “color” attribute.
There are lots of different ways to organize large data set depending on which problems you are trying to solve. I will not even attempt to say which is “better” for fear of starting a holy-war in the comments.
Latest Answers