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

Хм, не совсем уверен, что ваш вопрос.

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

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

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

Так же, как вы можете программировать с ориентированным объектом методология с компилятором без OO или наоборот, поэтому вы можете настроить реляционную базу данных без RDBMS или использовать RDBMS для хранения нереляционных данных.

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

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

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

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

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

большинство из того, что вы "знаете" - это неправильно.

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

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

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

большинство баз данных 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

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

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

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

Хорошая Реализация Реляционных Баз Данных = Атомарные Бункеры
Хорошая Реализация Нереляционных Баз Данных = Дикий Дикий Запад

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

Я не нахожу никакой ценности в kinkyness, я имею в виду, какой смысл изобретать колесо, которое уже круглое, и его вращение является пуленепробиваемым? Также поздравляю @Джерри Коффин за его ответ.