В чем разница между реляционной и нереляционной базой данных?

Я знаю, что такие решения, как MySQL, PostgreSQL и MS SQL Server, являются системами реляционных баз данных, а NoSQL, MongoDB и т. Д. - нереляционными СУБД.

Однако в чем разница между двумя типами систем?

Условия непрофессионала предпочтительнее.

Благодарю.

У реляционных баз данных есть математическая основа (теория множеств, реляционная теория), которая преобразована в SQL == язык структурированных запросов.

Многие формы NoSQL (например, основанные на документах, основанные на графах, основанные на объектах, хранилища значений ключей и т. Д.) Могут или не могут быть основаны на единой фундаментальной математической теории. Как правильно заметил С. Лотт, иерархические хранилища данных действительно имеют математическую основу. То же самое можно сказать и о графовых базах данных .

Я не знаю универсального языка запросов для баз данных NoSQL.

Хм, не совсем понимаю, в чем ваш вопрос.

В заголовке вы спрашиваете о базах данных (БД), тогда как в теле текста вы спрашиваете о системах управления базами данных (СУБД). Эти два вопроса совершенно разные и требуют разных ответов.

СУБД - это инструмент, который позволяет вам получить доступ к БД.

Помимо самих данных, БД - это концепция того, как эти данные структурированы.

Точно так же, как вы можете программировать с помощью методологии ориентированных объектов с помощью компилятора, не использующего объектно-ориентированный объект, или наоборот, вы можете настроить реляционную базу данных без СУБД или использовать СУБД для хранения нереляционных данных.

Я сосредоточусь на том, что означает реляционная база данных (RDB), и оставлю обсуждение того, что системы делают другим.

Реляционная база данных (концепция) - это структура данных, которая позволяет связывать информацию из разных «таблиц» или разных типов сегментов данных. Корзина данных должна содержать так называемый ключ или индекс (который позволяет однозначно идентифицировать любой атомарный фрагмент данных в корзине). Другие сегменты данных могут ссылаться на этот ключ, чтобы создать связь между их атомами данных и атомом, на который указывает ключ.

Нереляционная база данных просто хранит данные без явных и структурированных механизмов для связывания данных из разных сегментов друг с другом.

Что касается реализации такой схемы, если у вас есть бумажный файл с указателем, а в другом бумажном файле вы обращаетесь к указателю, чтобы получить соответствующую информацию, значит, вы реализовали реляционную базу данных, хотя и довольно простую. Итак, вы видите, что вам даже не нужен компьютер (конечно, без него он может стать очень утомительным), точно так же вам не нужна СУБД, хотя, возможно, СУБД - правильный инструмент для этой работы. Тем не менее, существуют различия в том, что могут делать различные инструменты, поэтому выбор правильного инструмента для работы может быть не таким уж простым.

Я надеюсь, что это достаточно непрофессиональные термины и поможет вам понять.

Большая часть того, что вы «знаете», неверно.

Во-первых, как регулярно (а иногда и резко) отмечают некоторые гуру в области реляционных исследований, SQL на самом деле не так близко подходит к теории отношений, как многие думают. Во-вторых, большая часть различий в "NoSQL" относительно мало связана с тем, является ли он реляционным или нет. Наконец, довольно сложно сказать, чем "NoSQL" отличается от SQL, потому что оба они представляют довольно широкий диапазон возможностей.

Единственное важное отличие, на которое вы можете рассчитывать, заключается в том, что почти все, что поддерживает SQL, поддерживает такие вещи, как триггеры в самой базе данных, то есть вы можете создавать правила в самой базе данных, которые предназначены для обеспечения постоянной внутренней согласованности данных. Например, вы можете настроить так, чтобы ваша база данных утверждала, что человек долженесть адрес. Если вы это сделаете, каждый раз, когда вы добавляете человека, это фактически заставит вас связать этого человека с каким-либо адресом. Вы можете добавить новый адрес или связать его с каким-либо существующим адресом, но так или иначе у человека должен быть адрес. Аналогичным образом, если вы удалите адрес, это заставит вас либо удалить всех людей, находящихся в данный момент на этом адресе, либо связать каждого с каким-либо другим адресом. Вы можете сделать то же самое для других отношений, например, сказать, что у каждого человека должна быть мать, у каждого офиса должен быть номер телефона и т. Д.

Обратите внимание , что эти виды вещей также гарантированно произойдет атомарно, так что если кто - то еще смотрит на базу данных , как вы добавляете человека, они либо не увидеть человека вообще, либо они будут видеть человека с адрес (или мать и т. д.)

Большинство баз данных NoSQL не пытается обеспечить такого рода принудительное исполнение в самой базе данных. Вам решать в коде, который использует базу данных, чтобы обеспечить соблюдение любых взаимосвязей, необходимых для ваших данных. В большинстве случаев также можно увидеть данные, которые верны только частично, поэтому даже если у вас есть генеалогическое древо, в котором каждый человек должен быть связан с родителями, могут быть случаи, когда любые ограничения, которые вы наложили, на самом деле не будут принудительно. Некоторые позволят вам сделать это по желанию. Другие гарантируют, что это происходит только временно, хотя точно, как долго это может / продлится, остается под вопросом.

Реляционная база данных использует формальную систему предикатов для адресации данных. Базовая физическая реализация не имеет существенного значения и может изменяться для оптимизации для определенных операций, но всегда должна предполагать реляционную модель . С точки зрения непрофессионала, это просто означает, что я точно знаю, сколько значений (атрибутов) имеет каждая строка (кортеж) в моей таблице (отношении), и теперь я хочу использовать этот факт соответственно, тщательно и до крайности. Это настоящая природа зверя. 

Поскольку мы, очевидно, поколение, которое выросло на реляционной основе, если вы посмотрите на модели баз данных NoSQL с точки зрения реляционной модели, опять же с точки зрения непрофессионала, первое очевидное отличие состоит в том, что никакие предположения о количестве значений в строке не могут содержать когда-либо сделано. Это действительно упрощает дело и не совсем применимо к сложностям физических моделей каждой базы данных NoSQL, но это вершина реляционной модели и первое предположение, которое мы должны оставить позади, или, если хотите, самое большое прыжок мы должны сделать.

Мы можем согласиться с двумя вещами, которые верны для любой СУБД: она может хранить любые данные и имеет достаточно математических основ, чтобы сделать возможным управление данными любым мыслимым способом. Реальность такова, что вы никогда не захотите совершить ошибку, проверив какую-либо из двух точек, а просто придерживайтесь того, для чего действительно была создана СУБД. Проще говоря: уважайте зверя внутри!

(Обратите внимание, что я избегал сравнения (очевидно) хорошо обоснованных стандартов, основанных на реляционной модели, с множеством разновидностей, предоставляемых базами данных NoSQL. Если хотите, рассматривайте базы данных NoSQL как общий термин для любой СУБД, которая не полностью Предположим, что реляционная модель исключена из всего остального. Различий слишком много, но это принципиальное отличие, которое, я думаю, будет наиболее полезно для вас, чтобы понять их.)

Попытайтесь объяснить этот вопрос на уровне, относящемся к технологиям.

Возьмите MongoDB и традиционный SQL для сравнения, представьте себе сценарий публикации твита в Twitter. Этот твит содержит 9 изображений. Как вы храните этот твит и соответствующие изображения?

С точки зрения традиционного SQL-запроса отношений, вы можете хранить твиты и изображения в отдельных таблицах и представлять соединение путем создания новой таблицы.

Более того, вы можете установить поле, которое является типом изображения, и заархивировать 9 изображений в двоичный документ и сохранить его в этом поле.

Используя MongoDB, вы можете создать такой документ (аналогичный концепции таблицы в реляционном SQL):

{

"id":"XXX",

"user":"XXX",

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

"content":{

"text":"XXXX",

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

}

Поэтому, на мой взгляд, основное различие заключается в том, как вы храните данные и на уровне хранения отношений между ними.

В этом примере данные - это твит и изображения. Различный механизм взаимосвязи уровня хранения между ними также играет важную роль в различии между ними.

Надеюсь, этот небольшой пример поможет показать разницу между SQL и NoSQL (ACID и BASE).

Вот ссылка на картинку о целях NoSQL из Интернета:

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

Именно в этом разница между реляционным и нереляционным. Архитектура реляционной базы данных предоставляет объекты ограничений, такие как первичные ключи, внешние ключи и т. Д., Что позволяет связать две или более таблиц в отношении. Это хорошо, так как мы нормализуем наши таблицы, то есть разделяем информацию о том, что представляет собой база данных, на множество разных таблиц, когда мы можем сохранить целостность данных.

Например, предположим, что у вас есть серия таблиц, в которых хранится информация о сотруднике. Вы не можете удалить запись из таблицы, не удалив все записи, относящиеся к такой записи, из других таблиц. Таким образом вы реализуете целостность данных. Нереляционная база данных не предоставляет конструкции ограничений, которые позволят вам реализовать целостность данных.

Если вы не реализуете это ограничение во внешнем приложении, которое используется для заполнения таблиц баз данных, вы создаете беспорядок, который можно сравнить с диким западом.

Прежде всего позвольте мне сказать, зачем нам нужна база данных.

Нам нужна база данных, чтобы помочь организовать информацию таким образом, чтобы мы могли эффективно извлекать хранимые данные.

Примеры систем управления реляционными базами данных (SQL):

1) База данных Oracle

2) SQLite

3) PostgreSQL

4) MySQL

5) Microsoft SQL Server

6) IBM DB2

Примеры систем управления нереляционными базами данных (NoSQL)

1) MongoDB

2) Кассандра

3) Redis

4) Диван

5) HBase

6) DocumentDB

7) Neo4j

Реляционные базы данных имеют нормализованные данные, поскольку информация хранится в таблицах в виде строк и столбцов, и обычно, когда данные находятся в нормализованной форме, это помогает уменьшить избыточность данных, а данные в таблицах обычно связаны друг с другом, поэтому, когда мы хотим получить данные, мы можем запрашивать данные с помощью операторов соединения и извлекать данные в соответствии с нашими потребностями. Это подходит, когда мы хотим иметь больше операций записи, меньше операций чтения и не задействовать много данных, также это действительно легко относительно обновлять данные в таблицах, чем в нереляционных базах данных. Горизонтальное масштабирование невозможно, вертикальное масштабирование возможно до некоторой степени. Соответствие требованиям CAP (согласованность, доступность, устойчивость к разделам) и ACID (атомарность, согласованность, изоляция, продолжительность).

Позвольте мне показать ввод данных в реляционную базу данных на примере PostgreSQL.

Сначала создайте таблицу продуктов следующим образом:

CREATE TABLE products (
    product_no integer,
    name text,
    price numeric
);

затем вставьте данные

INSERT INTO products (product_no, name, price) VALUES (1, 'Cheese', 9.99);

Давайте посмотрим на другой пример:

Здесь, в реляционной базе данных, мы можем связать таблицу учеников и таблицу предметов, используя отношения, через внешний ключ, идентификатор предмета, но в нереляционной базе данных нет необходимости иметь два документа, поскольку нет отношений, поэтому мы храним все детали предмета В сведениях о студенте в одном документе говорится, что это документ о студенте, а затем данные дублируются, что затрудняет обновление записей.

В нереляционных базах данных нет фиксированной схемы, данные не нормализованы. никаких связей между данными не создается, все данные в основном помещаются в один документ. Хорошо подходит для обработки большого количества данных и может передавать большое количество данных одновременно, лучше всего там, где большое количество операций чтения и меньше операций записи и меньше обновлений, что немного затрудняет запрос данных, так как нет фиксированной схемы. Возможно горизонтальное и вертикальное масштабирование, соответствие требованиям CAP (согласованность, доступность, устойчивость к разделам) и BASE (базовая доступность, мягкое состояние, согласованность в конечном итоге).

Позвольте мне показать пример ввода данных в нереляционную базу данных с помощью Mongodb.

db.users.insertOne({name: ‘Mary’, age: 28 , occupation: ‘writer’ })
db.users.insertOne({name: ‘Ben’ , age: 21})

Следовательно, вы можете понять, что в базе данных с именем db есть коллекции с именем users и документ с именем insertOne, в который мы добавляем данные, и нет фиксированной схемы, поскольку наша первая запись имеет 3 атрибута, а второй атрибут имеет только 2 атрибута , это не проблема в нереляционных базах данных, но не может быть сделано в реляционных базах данных, поскольку реляционные базы данных имеют фиксированную схему.

Давайте посмотрим на другой пример

({Studname: ‘Ash’, Subname: ‘Mathematics’, LecturerName: ‘Mr. Oak’})

Следовательно, мы можем видеть, что в нереляционной базе данных мы можем вводить как сведения о студенте, так и сведения о предмете в один документ, поскольку в нереляционных базах данных не определены отношения, но здесь этот способ может привести к дублированию данных, и, следовательно, могут возникнуть ошибки при обновлении.

Надеюсь, это все объясняет

С точки зрения непрофессионала, он сильно структурирован по сравнению с неструктурированным, что означает, что у вас есть разные степени адаптации для вашей БД. Различия возникают в индексации, в частности, потому, что вам необходимо убедиться, что определенный ссылочный индекс может ссылаться на другой элемент -> это отношение. Из этого требования вытекает более строгая структура реляционной БД.

Отметим, что NosDB предоставляет как реляционные, так и нереляционные БД, а также способ запроса как http://www.alachisoft.com/nosdb/sql-cheat-sheet.html