Quelle est la différence entre une base de données relationnelle et non consanguine?

Question

Je sais que des solutions comme MySQL, PostgreSQL et MS SQL Server sont des systèmes de bases de données relationnelles et NoSQL, MongoDB, etc. sont SGBD non-relationnel.

Cependant, quelles sont les différences entre les deux types de système?

termes simples sont préférables.

Merci.

Answer 1

Bases de données relationnelles ont une base mathématique (théorie des ensembles, la théorie relationnelle), qui sont distillés dans SQL == langage d'interrogation structuré.

de nombreuses formes de NoSQL (par exemple document à base graphique basée, magasin, valeur clé à base d'objets, etc.) peuvent ou ne peuvent pas se fonder sur un seul fondement théorie mathématique. Comme S. Lott a souligné à juste titre, hiérarchique magasins de données ont en effet une base mathématique. La même chose pourrait être dit graphique des bases de données .

Je ne suis pas au courant d'un langage de requête universel pour les bases de données NoSQL.

Answer 2

Hmm, pas tout à fait sûr de votre question.

Dans le titre que vous posez des questions sur les bases de données (DB), alors que dans le corps de votre texte que vous posez des questions sur la base de données des systèmes de gestion (SGBD). Les deux sont complètement différents et nécessitent des réponses différentes.

Un SGBD est un outil qui vous permet d'accéder à une base de données.

autres que les données lui-même, un DB est le concept de la façon dont ces données sont structurées.

Alors comme vous pouvez programmer avec la méthodologie orientée objet avec un compilateur alimenté non-OO, ou vice-versa, de sorte que vous pouvez mettre en place une base de données relationnelle sans SGBDR ou utiliser un SGBDR pour stocker des données non relationnelles.

Je vais me concentrer sur ce que la base de données relationnelle moyens (BDR) et de laisser la discussion sur ce que les systèmes font aux autres.

Une base de données relationnelle (le concept) est une structure de données qui vous permet d'informations de liaison de différentes « tables », ou différents types de godets de données. Un seau de données doit contenir ce qu'on appelle une clé ou d'un index (qui permet d'identifier de manière unique tout morceau atomique de données dans le seau). D'autres seaux de données peuvent se référer à cette touche de manière à créer un lien entre les atomes de données et l'atome pointé par la clé.

Une base de données non relationnelle seulement stocke les données sans mécanismes explicites et structurés aux données de liaison de différents seaux à l'autre.

En ce qui concerne la mise en œuvre d'un tel système, si vous avez un fichier de papier avec un index et dans un fichier papier différent vous référer à l'index pour obtenir l'information pertinente, vous avez mis en place une base de données relationnelle, quoique assez simple . Donc, vous voyez que vous ne même pas besoin d'un ordinateur (bien sûr, il peut devenir fastidieux très rapidement sans un à l'aide), de même que vous n'avez pas besoin d'un SGBDR, mais sans doute un SGBDR est le bon outil pour le travail. Cela dit, il y a des variations quant à ce que les différents outils là-bas peut faire le choix de l'outil pour le travail ne peut pas être tout aussi simple que cela.

J'espère que cela est assez termes simples et utiles à votre compréhension.

Answer 3

Most of what you "know" is wrong.

First of all, as a few of the relational gurus routinely (and sometimes stridently) point out, SQL doesn't really fit nearly as closely with relational theory as many people think. Second, most of the differences in "NoSQL" stuff has relatively little to do with whether it's relational or not. Finally, it's pretty difficult to say how "NoSQL" differs from SQL because both represent a pretty wide range of possibilities.

The one major difference that you can count on is that almost anything that supports SQL supports things like triggers in the database itself -- i.e. you can design rules into the database proper that are intended to ensure that the data is always internally consistent. For example, you can set things up so your database asserts that a person must have an address. If you do so, anytime you add a person, it will basically force you to associate that person with some address. You might add a new address or you might associate them with some existing address, but one way or another, the person must have an address. Likewise, if you delete an address, it'll force you to either remove all the people currently at that address, or associate each with some other address. You can do the same for other relationships, such as saying every person must have a mother, every office must have a phone number, etc.

Note that these sorts of things are also guaranteed to happen atomically, so if somebody else looks at the database as you're adding the person, they'll either not see the person at all, or else they'll see the person with the address (or the mother, etc.)

Most of the NoSQL databases do not attempt to provide this kind of enforcement in the database proper. It's up to you, in the code that uses the database, to enforce any relationships necessary for your data. In most cases, it's also possible to see data that's only partially correct, so even if you have a family tree where every person is supposed to be associated with parents, there can be times that whatever constraints you've imposed won't really be enforced. Some will let you do that at will. Others guarantee that it only happens temporarily, though exactly how long it can/will last can be open to question.

Answer 4

The relational database uses a formal system of predicates to address data. The underlying physical implementation is of no substance and can vary to optimize for certain operations, but it must always assume the relational model. In layman's terms, that's just saying I know exactly how many values (attributes) each row (tuple) in my table (relation) has and now I want to exploit the fact accordingly, thoroughly and to it's extreme. That's the true nature of the beast. 

Since we're obviously the generation that has had a relational upbringing, if you look at NoSQL database models from the perspective of the relational model, again in layman's terms, the first obvious difference is that no assumptions about the number of values a row can contain is ever made. This is really oversimplifying the matter and does not cleanly apply to the intricacies of the physical models of every NoSQL database, but it's the pinnacle of the relational model and the first assumption we have to leave behind or, if you'd rather, the biggest leap we have to make.

We can agree to two things that are true for every DBMS: it can store any kind of data and has enough mathematical underpinnings to make it possible to manage the data in any way imaginable. The reality is that you'll never want to make the mistake of putting any of the two points to the test, but rather just stick with what the actual DBMS was really made for. In layman's terms: respect the beast within!

(Please note that I've avoided comparing the (obviously) well founded standards revolving around the relational model against the many flavors provided by NoSQL databases. If you'd like, consider NoSQL databases as an umbrella term for any DBMS that does not completely assume the relational model, in exclusion to everything else. The differences are too many, but that's the principal difference and the one I think would be of most use to you to understand the two.)

Answer 5

Try to explain this question in a level referring to a little bit technology

Take MongoDB and Traditional SQL for comparison, imagine the scenario of posting a Tweet on Twitter. This tweet contains 9 pictures. How do you store this tweet and its corresponding pictures?

In terms of traditional relationship SQL, you can store the tweets and pictures in separate tables, and represent the connection through building a new table.

What's more, you can set a field which is an image type, and zip the 9 pictures into a binary document and store it in this field.

Using MongoDB, you could build a document like this (similar to the concept of a table in relational SQL):

{

"id":"XXX",

"user":"XXX",

"date":"xxxx-xx-xx",

"content":{

"text":"XXXX",

"picture":["p1.png","p2.png","p3.png"]

}

Therefore, in my opinion, the main difference is about how do you store the data and the storage level of the relationships between them.

In this example, the data is the tweet and the pictures. The different mechanism about storage level of relationship between them also play a important role in the difference between both.

I hope this small example helps show the difference between SQL and NoSQL (ACID and BASE).

Here's a link of picture about the goals of NoSQL from the Internet:

http://icamchuwordpress-wordpress.stor.sinaapp.com/uploads/2015/01/dbc795f6f262e9d01fa0ab9b323b2dd1_b.png

Answer 6

The difference between relational and non-relational is exactly that. The relational database architecture provides with constraints objects such as primary keys, foreign keys, etc that allows one to tie two or more tables in a relation. This is good so that we normalize our tables which is to say split information about what the database represents into many different tables, once can keep the integrity of the data.

For example, say you have a series of table that houses information about an employee. You could not delete a record from a table without deleting all the records that pertain to such record from the other tables. In this way you implement data integrity. The non-relational database doesn't provide this constraints constructs that will allow you to implement data integrity.

Unless you don't implement this constraint in the front end application that is utilized to populate the databases' tables, you are implementing a mess that can be compared with the wild west.

Answer 7

In layman terms it's strongly structured vs unstructured, which implies that you have different degrees of adaptability for your DB. Differences arise in indexation particularly as you need to ensure that a certain reference index can link to a another item -> this a relation. The more strict structure of relational DB comes from this requirement.

To note that NosDB apaprently provides both relational and non relational DBs and a way to query both http://www.alachisoft.com/nosdb/sql-cheat-sheet.html