Я знаю, что такие решения, как MySQL, PostgreSQL и MS SQL Server, являются реляционными системами баз данных, а NoSQL, MongoDB и т.д. являются нереляционными СУБД.
Однако каковы различия между двумя типами систем?
Предпочтительны термины Layman.
Спасибо.
Реляционные базы данных имеют математическую основу (теория множеств, реляционная теория), которые перегоняются в SQL == Структурированный язык запросов.
NoSQL многие формы (например, основанные на документах, основанные на графике, основанные на объектах, хранилище ключей и т.д.) могут основываться или не основываться на единой основополагающей математической теории. Как справедливо указал С. Лотт, hierarchical хранилища данных действительно имеют математическую основу. То же самое можно сказать и о графических базах данных.
Я не знаю универсальный язык запросов для баз данных NoSQL.
Хм, не совсем уверен, каков ваш вопрос.
В заголовке вы спрашиваете о Базах данных (БД), тогда как в тексте вашего тела вы спрашиваете о системах управления базами данных (СУБД). Они совершенно разные и требуют разных ответов.
СУБД - это инструмент, который позволяет вам обращаться к БД.
Помимо самих данных, БД представляет собой концепцию структурирования этих данных.
Так же, как вы можете программировать с помощью методологии Oriented Object с помощью компилятора, отличного от OO, или наоборот, так что вы можете настроить реляционную базу данных без RDBMS или использовать RDBMS для хранения нереляционных данных.
Я сосредоточу внимание на том, что означает Реляционная база данных (RDB), и оставьте обсуждение о том, какие системы делают с другими.
Реляционная база данных (концепция) - это структура данных, которая позволяет вам связывать информацию из разных таблиц или разных типов ведра данных. Ведро данных должно содержать то, что называется ключом или индексом (что позволяет однозначно идентифицировать любой атомный кусок данных в ведре). Другие ведра данных могут ссылаться на этот ключ, чтобы создать связь между атомами данных и атомом, на который указывает ключ.
Не реляционная база данных просто хранит данные без явных и структурированных механизмов для связывания данных из разных ведер друг с другом.
Что касается реализации такой схемы, если у вас есть бумажный файл с индексом и в другом бумажном файле, то вы ссылаетесь на индекс, чтобы получить соответствующую информацию, то вы внедрили реляционную базу данных, хотя и довольно простое, Таким образом, вы видите, что вам даже не нужен компьютер (конечно, он может стать утомительным очень быстро, без помощи), аналогично вам не нужна РСУБД, хотя, возможно, RDBMS является правильным инструментом для работы. Это говорит о том, что существуют различные варианты того, что различные инструменты там могут сделать, чтобы выбрать правильный инструмент для работы, возможно, не все так просто.
Я надеюсь, что это непрофессиональные условия достаточно и полезны для вашего понимания.
Большая часть того, что вы "знаете", неверна.
Прежде всего, поскольку некоторые из реляционных гуру обычно (а иногда и резко) указывают на то, что SQL действительно не так тесно связан с реляционной теорией, как думают многие люди. Во-вторых, большинство различий в материалах "NoSQL" относительно мало связано с реляционными или нет. Наконец, довольно сложно сказать, как "NoSQL" отличается от SQL, потому что оба представляют довольно широкий диапазон возможностей.
Единственное существенное отличие, на которое вы можете рассчитывать, состоит в том, что почти все, что поддерживает SQL, поддерживает такие вещи, как триггеры в самой базе данных - то есть вы можете создавать правила в самой базе данных, которые предназначены для обеспечения того, чтобы данные всегда были внутренне согласованы, Например, вы можете настроить все, чтобы ваша база данных утверждала, что у человека должен быть адрес. Если вы это сделаете, в любое время, когда вы добавите человека, это в основном заставит вас связать этого человека с каким-то адресом. Вы можете добавить новый адрес или связать их с каким-либо существующим адресом, но так или иначе, у человека должен быть адрес. Аналогичным образом, если вы удалите адрес, это заставит вас либо удалить всех людей, находящихся в данный момент на этом адресе, либо связать их с каким-либо другим адресом. Вы можете сделать то же самое для других отношений, например, говорить, что у каждого человека должна быть мать, у каждого офиса должен быть номер телефона и т.д.
Обратите внимание, что подобные вещи также гарантированно происходят атомарно, поэтому, если кто-то еще смотрит на базу данных, когда вы добавляете человека, они либо не видят человека вообще, либо они будут видеть лицо с адресом (или матерью и т.д.)
Большинство баз данных NoSQL не пытаются обеспечить такое принудительное применение в самой базе данных. Это зависит от вас, в коде, который использует базу данных, для обеспечения любых отношений, необходимых для ваших данных. В большинстве случаев также можно видеть данные, которые только частично исправляются, поэтому даже если у вас есть генеалогическое древо, где каждый человек должен быть связан с родителями, могут быть случаи, когда любые ограничения, которые вы наложили, на самом деле не будут исполнение. Некоторые позволят вам сделать это по своему усмотрению. Другие гарантируют, что это происходит только временно, хотя точно, как долго он может/будет длиться, может быть открытым вопрос.
Реляционная база данных использует формальную систему предикатов для адресации данных. Основная физическая реализация не имеет никакого значения и может варьироваться для оптимизации для определенных операций, но она всегда должна предполагать реляционную модель . В неспециалистских терминах, просто говоря, что я точно знаю, сколько значений (атрибутов) каждой строки (кортежа) в моей таблице (отношении) есть, и теперь я хочу использовать этот факт соответствующим образом, тщательно и крайне экстремально. Это истинный характер зверя.
Поскольку мы, очевидно, являемся поколением, имеющим реляционное воспитание, если вы посмотрите на модели базы данных NoSQL с точки зрения реляционной модели, опять же в непрофессиональных терминах, первое очевидное различие заключается в том, что никаких предположений о количестве значений строка может содержать всегда. Это действительно упрощает этот вопрос и не относится к тонкостям физических моделей каждой базы данных NoSQL, но это вершина реляционной модели и первое предположение, которое мы должны оставить или, если хотите, самый большой прыжок, который мы должны сделать.
Мы можем согласиться на две вещи, которые верны для каждой СУБД: она может хранить любые данные и иметь достаточные математические основы, чтобы можно было управлять данными любым возможным способом. Реальность такова, что вы никогда не захотите совершить ошибку, поставив любую из двух точек на тест, а просто придерживайтесь того, что действительно было создано для СУБД. В неспециалистских терминах: уважайте зверя внутри!
(Пожалуйста, обратите внимание, что я избежал сравнения (явно) обоснованных стандартов, вращающихся вокруг реляционной модели, против многих разновидностей, предоставляемых базами данных NoSQL. Если вы хотите, рассмотрите базы данных NoSQL в качестве зонтичного термина для любых СУБД, которые не полностью принимает реляционную модель, исключая все остальное. Различий слишком много, но главное отличие и то, что я думаю, будет наиболее полезно для вас, чтобы понять их.)
Попробуйте объяснить этот вопрос на уровне, относящемся к немного технологии
Возьмите MongoDB и традиционный SQL для сравнения, представьте себе сценарий размещения Tweet на 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 из Интернета:
Разница между реляционными и нереляционными заключается именно в этом. Архитектура реляционной базы данных содержит объекты ограничений, такие как первичные ключи, внешние ключи и т.д., Что позволяет связать две или более таблицы в отношении. Это хорошо, так что мы нормализуем наши таблицы, которые, как говорят, разделяют информацию о том, что представляет база данных во множество разных таблиц, однажды могут сохранить целостность данных.
Например, скажем, у вас есть серия таблиц с информацией о сотруднике. Вы не можете удалить запись из таблицы, не удаляя все записи, относящиеся к такой записи, из других таблиц. Таким образом, вы внедряете целостность данных. В нереляционной базе данных не предусмотрены эти конструкции ограничений, которые позволят вам реализовать целостность данных.
Если вы не реализуете это ограничение в интерфейсном приложении, которое используется для заполнения таблиц баз данных, вы реализуете беспорядок, который можно сравнить с диким западом.
