Pregunta no-sql relations

Question

Estoy dispuesto a darle una oportunidad seria a MongoDB y CouchDB. Hasta ahora he trabajado un poco con Mongo, pero también estoy intrigado por el enfoque RESTful de Couch.

Después de haber trabajado durante años con DB relacionales, todavía no entiendo cuál es la mejor manera de hacer algunas cosas con bases de datos no relacionales.

Por ejemplo, si tengo 1000 tiendas de autos y 1000 tipos de automóviles, quiero especificar qué tipo de autos vende cada tienda. Cada auto tiene 100 características. Dentro de una base de datos relacional, crearía una mesa intermedia para vincular cada tienda de autos con los tipos de autos que vende a través de ID. ¿Cuál es el enfoque de No-sql? Si cada tienda de autos vende 50 tipos de autos, significa replicar una gran cantidad de datos, si tengo que almacenar dentro de la tienda de autos todas las características de todos los tipos de autos que vende.

Cualquier ayuda apreciada.

Answer 1

Viniendo de un punto de vista de HBase/BigTable, normalmente usted desnormalizaría completamente sus datos, y usaría un campo de "lista", o una columna de mapa multidimensional (vea este link para una mejor descripción).

La palabra "columna" es otro cargado palabra como "mesa" y "base", que lleva la carga emocional de años de la experiencia RDBMS.

En su lugar, me resulta más fácil pensar sobre esto como un mapa multidimensional - un mapa de mapas si se quiere.

Para su ejemplo de una relación muchos a muchos, puede crear dos tablas y usar su columna de mapa multidimensional para mantener la relación entre las tablas.

Ver las preguntas frecuentes pregunta 20 en el Hadoop/HBase FAQ:

Q: [Michael Dagaev] ¿Cómo diseñar una tabla de hbase para muchos-a-muchos asociación entre dos entidades, por ejemplo Estudiante y Curso?

Me definir dos tablas: Estudiante: Estudiante los datos de identificación del estudiante (nombre, dirección, ...) (IDS uso de etapas como las columnas calificadores aquí) cursos Curso: Identificación del datos del curso del curso (nombre, programa de estudios , ...) estudiantes (use los identificadores de estudiante como calificadores de la columna aquí) ¿Tiene sentido?

A [Jonathan Gray]: Su diseño hace tiene sentido. Como dijiste, es probable que tenga dos familias de columnas en en cada una de las tablas de Estudiantes y Cursos. Uno de los datos, otro con una columna por estudiante o curso. Para el ejemplo , una fila de estudiante podría parecerse a como: Estudiante: id/fila/clave = 1001 data: name = Datos del nombre del estudiante: dirección = 123 ABC St courses: 2001 = (Si necesita más información sobre esta asociación , por ejemplo, si son en la lista de espera) cursos: 2002 = ...Este esquema le brinda acceso rápido a las consultas, muestra todas las clases para un estudiante (tabla de estudiantes, cursos familia), o todos los estudiantes para una clase (tabla de cursos, familia de estudiantes).

Answer 2

En MongoDB un enfoque de uso frecuente sería almacenar una lista de _ids de tipos de automóviles en cada tienda de automóviles. Así que no hay una tabla de unión por separado, pero básicamente sigue haciendo una unión del lado del cliente.

Los documentos integrados se vuelven más relevantes para casos que no son muchos a muchos como este.

Answer 3

Solo puedo hablar con CouchDB.

La mejor manera de insertar sus datos en el archivo db es no normalizarlo más allá de convertirlo a JSON. Si esos datos son "autos", pegue todos los datos de cada automóvil en la base de datos.

Luego utiliza map/reduce para crear un índice normalizado de los datos. Por lo tanto, si desea un índice de cada automóvil, ordenado primero por tienda, luego por tipo de automóvil, usted emitiría cada automóvil con un índice de [tienda, tipo de automóvil].

Reducir mapas parece un poco aterrador al principio, pero no es necesario que entiendas todas las cosas complicadas o incluso las btrees, todo lo que necesitas entender es cómo funciona la clasificación por clave.

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

Con eso solo puede crear sorprendentes índices normalizados sobre diferentes documentos con el mapa reducir el sistema de CouchDB.

Answer 4

En la base de datos relacional, el concepto es muy claro: una tabla para automóviles con columnas como "car_id, car_type, car_name, car_price" y otra tabla para tiendas con columnas "shop_id, car_id, shop_name, sale_count", the " car_id "une las dos tablas para datos Ops. Todas las columnas deben estar bien definidas al crear la base de datos.

Ningún sistema de base de datos SQL requiere que usted defina previamente estas columnas y tablas. Usted acaba de construir sus registros en un formato determinado, digamos JSON, como:

"{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]}", 
..... 

Después de que su sistema está en línea que proporciona servicio para su gestión, se puede encontrar que hay algunos defectos en el diseño de la estructura del DB, espero agregar una columna "empleado" de "tienda" para sus registros futuros. Entonces sus nuevos registros serán:

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

Ningún sistema SQL le permite hacerlo, pero la base de datos relacional es imposible para este trabajo.