Нет отношений вопрос

Question

Я готов серьезно попробовать MongoDB и CouchDB. До сих пор я немного работал с Mongo, но меня также заинтриговал подход RESTful от Couch.

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

Например, если у меня есть 1000 автомагазинов и 1000 типов автомобилей, я хочу указать, какие машины продаются в каждом магазине. Каждый автомобиль имеет 100 функций. В реляционной базе данных я составил бы промежуточную таблицу, чтобы связать каждый магазин автомобилей с типами автомобилей, которые он продает через идентификаторы. Каков подход No-sql? Если каждый автомобильный магазин продает 50 типов автомобилей, это означает тиражирование огромного количества данных, если мне нужно хранить в автомобильном магазине все функции всех типов автомобилей, которые он продает!

Любая помощь приветствуется.

Answer 1

Я могу говорить только с CouchDB.

Лучший способ поместить ваши данные в БД - это вообще не нормализовать их, кроме как преобразовать их в JSON. Если эти данные "автомобили", то добавьте все данные о каждой машине в базу данных.

Затем вы используете map / lower для создания нормализованного индекса данных. Таким образом, если вы хотите, чтобы индекс каждого автомобиля сортировался сначала по магазинам, а затем по типу автомобиля, вы бы отправляли каждый автомобиль с индексом [магазин, тип автомобиля].

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

http://wiki.apache.org/couchdb/View_collation

С этим одним вы можете создавать удивительные нормализованные индексы для разных документов с помощью системы сокращения карт в CouchDB.

Answer 2

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

Внедренные документы становятся более актуальными для дел, которые не так много для многих, как этот.

Answer 3

В реляционной базе данных концепция очень ясна: одна таблица для автомобилей со столбцами типа "car_id, car_type, car_name, car_price", а другая таблица для магазинов с столбцами "shop_id, car_id, shop_name, sale_count", "car_id "связывает две таблицы вместе для данных Ops. Все столбцы должны быть четко определены при создании базы данных.

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

"{car:[id:1, type:auto, name:ford], shop:[id:100, name:some_shop]}",  
"{car:[id:2, type:auto, name:benz], shop:[id:105, name:my_shop]}",  
.....  

После того, как ваша система онлайн предоставит сервис для вашего управления, вы можете обнаружить, что в вашей структуре структуры БД есть некоторые недостатки, вы надеетесь добавить один столбец "employee" из "shop" для ваших будущих записей. Тогда ваши новые записи будут выглядеть так:

"{car:[id:3, type:auto, name:RR], shop:[id:108, name:other_shop, employee:Bill]}",  

Ни одна система SQL не позволяет вам этого делать, но для этой работы реляционная база данных невозможна.

Answer 4

Исходя из точки зрения HBase / BigTable, обычно вы полностью денормализуете свои данные и будете использовать поле «список» или столбец многомерной карты (более подробное описание см. В этой ссылке ).

Слово "столбец" является другим загруженным слово, как «стол» и «база», которые несет эмоциональный багаж лет опыта СУБД.

Вместо этого мне легче думать об этом, как многомерная карта - карта карт, если хотите.

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

См. Вопрос 20 часто задаваемых вопросов в Hadoop / HBase FAQ :

В: [Михаил Дагаев] Как бы вы разработать таблицу Hbase для многих ко многим ассоциация между двумя объектами, для пример студент и курс?

Я бы определить две таблицы: студент: студент Идентификатор студента (имя, адрес, ...) курсы (используйте идентификаторы курсов в качестве столбца классификаторы здесь) Course: id курса данные курса (название, учебный план, ...) студенты (используйте идентификаторы студентов в качестве столбца классификаторы тут) имеет ли смысл?

A [Джонатан Грей]: Ваш дизайн делает имеет смысл. Как вы сказали, вы бы вероятно, есть два семейства столбцов в каждый из столов ученика и курса. Один для данных, другой с колонка на студента или курс. За Например, строка студента может выглядеть как: студент: id / row / key = 1001 данные: имя = имя студента данные: адрес = 123 ABC St курсы: 2001 = (Если вам нужно больше информации об этом ассоциация, например, если они в листе ожидания) курсы: 2002 = ... Эта схема дает вам быстрый доступ на запросы, показать все классы для студент (ученический стол, курсы семья) или все ученики для одного класса (столы для курсов, семья студентов).