Historias
Slashboxes
Comentarios
 

Login Barrapunto

Login

[ Crear nueva cuenta ]

Modelo de BBDD para muchas relaciones entre dos elementos

Entrada escrita por tnt80 y editada por Mu el Martes, 13 Noviembre de 2012, 11:08h   Printer-friendly   Email story
desde el dept. piezas-y-coches,-son-metáforas
Hola a todo el mundo: Tengo una pequeña consulta acerca de un modelo para una base de datos. Como es muy difícil de explicar, utilizaré una pequeña alegoría: Supongamos que tienes un montón de piezas de coche (por ejemplo) y también un montón de modelos de coches para meter en una base de datos. Cada modelo de coche indexado en la base de datos tendrá un conjunto de piezas, y de cada pieza, una o más. Tú quieres un modelo de base de datos que relacione los modelos de coches con las piezas que pueden contener. Si en tu modelo de base de datos, relaciones, en alguna tabla, directamente los modelos de coches con las piezas, podrás buscar qué coches contienen qué piezas, pero dicha tabla tendría un tamaño enorme, que crecería conforme se fuesen añadiendo modelos de coche y piezas. Otra alternativa sería que cada modelo de coche contuviese una pequeña tabla con el código de las piezas que contiene y la cantidad de las mismas, pero eso haría más costosas las búsquedas como la de "qué modelos de coche contienen una pieza dada" al prácticamente obligar a meterte en todos los modelos de coches. Aclaro que lo de los modelos de coches y sus piezas son una alegoría de otra cosa, el resto de la problemática es la misma. El caso es que se trata de una cantidad de objetos enorme, y una cantidad de entidades que "contienen" esos objetos también enorme. Y me interesa maximizar las capacidades de búsqueda por ambos lados, pero el modelo que tengo en mente que lo permite, requeriría una base de datos enorme. ¿Alguna idea? Muchas gracias de antemano (y perdón por el rollazo).

Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • Puede ser que el tamaño no importe

    (Puntos:3, Informativo)
    por saisyukusanagi (27227) el Martes, 13 Noviembre de 2012, 11:42h (#1324234)
    ( http://barrapunto.com/~saisyukusanagi | Última bitácora: Viernes, 20 Junio de 2008, 05:04h )
    Muchas veces en esos modelos de bases de datos "sin salida" puedes contar con las ventajas que cada motor te ofrece, parece cobrar sentido para este caso el concepto de particionado de tablas, en donde puedes por ejemplo tener una tabla de 100 millones de registros seccionada en 100 tablas de un millon o 400 de 250 mil, y para el desarrollo seguira siendo una sola. Si la computacion se queda corta entonces puedes ir pensando en otro concepto: federacion, donde puedes enviar a otro servidor las tablas mas conflictivas.

    Mi experiencia al respecto es que muchas veces se dimensiona una base de datos a futuro suponiendo que el crecimiento quizá va a ser exponencial y la verdad es que estas cosas no suelen suceder, créeme que si la concurrencia a dicha tabla no es muy alta (digamos, diezmil consultas por hora) puedes tener entre cinco a diez millones de registros y en un hardware decente y con un desarrollo correcto no vas a tener dolores de cabeza.
    [ Responder ]
  • Muchos a muchos

    (Puntos:2, Interesante)
    por adehoces (33439) el Martes, 13 Noviembre de 2012, 12:06h (#1324239)
    No creo que te quede otra que la clásica tabla [ ID-coche / ID-pieza / contador ]. Con su índice correspondiente no deberías tener problemas de rendimiento. No entiendo exactamente qué limitaciones tienes respecto al espacio, pero poca solución le veo. Tener una tabla por coche como dices complica mucho la lógica de consultas (y de todo lo demás), y sólo reduce el número de registros por cada tabla, no el número total de registros. También hay formas lógicas de reducir el número de registros, por ejemplo tener una tabla con [ID-coche / String-de-componentes] y en el string incluir una especie de mapa codificado de las piezas (ej. "(23323)14-(42422)28", indicando que de la pieza 23323 hay 14 y de la 42422 hay 28). Para saber qué coches tienen una determinada pieza podrías hacer un SELECT ID-coche FROM Mapas WHERE String-de-componentes LIKE '%(xxxxx)%'. Pero esto, además de chapucero e ineficiente, al final ocupa más espacio real aunque reduzca el número de registros. Igual si especificas un poco más se puede afinar algo, intentando aprovechar características concretas de tu caso (un coche no tendrá nunca mas de X piezas diferentes, hay pocos coches pero muchas piezas o viceversa, hay más consultas por coche que por pieza...). Pero a fin de cuentas no es más que un "many to many". Luego ya puedes jugar con particionado, materialized views, tablas temporales, cachés o cosas así para afinar rendimiento, dependiendo de que tipo de consultas se vayan a realizar con más frecuencia.
    [ Responder ]
  • Normalizacion

    (Puntos:2)
    por neu___ (14363) el Martes, 13 Noviembre de 2012, 12:06h (#1324240)
    ( http://www.cpsaez.com/ | Última bitácora: Martes, 20 Noviembre de 2012, 16:31h )
    Tu modelo es una tabla normalizada y lo que tu tienes en mente es desnormalizarla (poniendo el codigo de la pieza en vez de su ID y cosas asi).

    Si esto es correcto, desnormalizarla te va a crear una BBDD mas grande que una normalizada, ademas de que con unos buenos indices, las consultas sobre codigos (nada de likes) deberian ir voladas.

    No entiendo tu problema a o ser que estes intentando modelizar el universo o algo asi de grande.
    --

    Under a sea of dust lies a vast wealth of wisdom

    [ Responder ]
  • por Noradrex (3519) <noradrex@gmail.com> el Martes, 13 Noviembre de 2012, 14:56h (#1324276)
    ( http://labotelladeklein.blogspot.com/ | Última bitácora: Sábado, 21 Julio de 2012, 18:01h )
    Como otros comentan, soy de la opinión de que lo que planteas es algo manejable de manera estándar por un SGDB decente, pero si quieres quitarte asegurarte, lo mejor es probar... Si hablamos de un número de tablas tan pequeño, puedes desde montar un Mysql/SQL Server/MongoDB en local y llenarlo para ver como tira eso en un equipo, sin programación, tan solo usando consultas a pelo. Y si quieres ver otras alternativas, una trial de 90 días de Azure debería permitirte experimentar con un SQL Server (as a service) o un poco de NoSQL (Azure Table Storage [windowsazure.com])
    --

    El doble de diversión en: La Botella de Klein [blogspot.com]

    [ Responder ]
    • Cambia el modelo de pobrecito hablador (Puntos:1) Martes, 13 Noviembre de 2012, 15:53h
  • En dos palabras

    (Puntos:1, Divertido)
    por pobrecito hablador el Martes, 13 Noviembre de 2012, 16:12h (#1324289)
    DBASE III
    Bueno, y si la cosa está chunga DBASE IV
    [ Responder ]
  • por Klam (10142) <camiloaa@jabber.org> el Martes, 13 Noviembre de 2012, 17:01h (#1324307)
    ( http://camiloaa.blogspot.com/ )
    El asunto a fin de cuentas siempre es dinero. Oracle y DB2 pueden manejar índices de cientos de millones de elementos sin problema. Pero claro, eso implica mucho dinero en software y hardware.

    En opciones mas baratas se me ocurren:
    - Agrupar: En vez de listar todas las piezas del auto, creas una tabla de "puertas", "motores" y demás, con lo que tienes tablas de relación mas pequeñas (piezas-puerta, piezas-motor).
    - NoSQL. Utilizas un árbol ordenado para piezas-auto y otro para auto-piezas, mantienes la integridad de los datos por software, y lo enlazas (también por software) con la base de datos. Si la relación entre piezas y autos no es demasiado compleja, el software tampoco tendría por que serlo. Eso sí, no puedes hacer consultas ni insertar nada directamente en la base de datos.

    Pero por supuesto las mejores soluciones implican un conocimiento profundo de los datos. Alguien comentó que tal vez te resultara mas fácil listar que piezas NO se usan en un coche, y aunque no sea la solución que tu necesitas, tal vez sea una buena idea considerar ese tipo de soluciones. ¿Hay menos excepciones que casos regulares? ¿Es mas fácil desnormalizar? ¿Hay mas lecturas que escrituras? ¿Hay búsquedas mas populares que otras?
    [ Responder ]
  • Tomas Elp Elo

    (Puntos:1, Divertido)
    por pobrecito hablador el Martes, 13 Noviembre de 2012, 18:02h (#1324313)
    Estoy empezando con el PHP y con el Node.js y creo que ya le he pillado el truco a estas cosas. Yo lo quye haría es lo siguiente:

    Pon los datos en un excel guardado como csv, haz un zip del excel, luego un rar del zip, luego otro zip del rar, etc... y así sucesivamente hasta que la base de datos te quepa en la ram. Cuando llegue a caberte toda entera en la ram ya ira rápida por si sola, porqué estará toda cacheada. Y como el zip y el rar son sistema de compresión indexados, puedes hacer consultas de datos sin problemas de rendimiento.
    [ Responder ]
  • por versae (29959) el Miércoles, 14 Noviembre de 2012, 00:18h (#1324344)
    ( http://versae.es/ )
    Si tienes muchos elementos, del orden de miles de millones, y un buen montón de relaciones entre ellos, pero quieres que las búsquedas sean rápidas, lo mejor es usar una base de datos en grafo como Neo4j [neo4j.org] u OrientDB [orientdb.org].
    --
    Menos da una piedra
    [ Responder ]
  • por santi (7180) <scamps conlaarroba earcon.com> el Miércoles, 14 Noviembre de 2012, 09:07h (#1324355)
    ( http://kmkey-es.blogspot.com/ )
    Si no estamos hablando de un producto cartesiano de más de 100 millones de registros, PostgreSQL te aguantará bien. Si vas más allá, busca por BigData, yo te recomiendo Cassandra. NO te gastes un dineral en DB2 ni Oracle, no vale la pena, hay alternativas libres suficientes.
    [ Responder ]
  • Tres tablas

    (Puntos:1)
    por Jerbo (50319) el Miércoles, 14 Noviembre de 2012, 22:03h (#1324451)
    En un SGBD relacional tendrías que optar por la opción segunda.
    Necesitarías 3 tablas, dos principales (modelos, tipo_de_pieza) y otra secundaria, resultado de la relación varios a varios de ambas tablas, que se llamaría, por ejemplo, piezas-modelo.
    En ésta última estarían los campos identificadores de modelo y de pieza, además del campo cantidad de esa pieza. Las consultas irían sobre los identificadores de modelo y/o pieza de esa tabla derivada.
    La cantidad de registros de ésta tabla: [cantidad modelos] x [cantidad de tipos de piezas media por modelo], perogrullescamente hablando
    [ Responder ]
  • Re:Tamaño?

    (Puntos:1)
    por tnt80 (27562) el Martes, 13 Noviembre de 2012, 12:10h (#1324243)
    ( Última bitácora: Martes, 13 Noviembre de 2012, 09:35h )
    Para el ejemplo que he puesto: - Un coche puede tener decenas de miles (o cientos de miles) de piezas. - Existen cientos de miles de modelos de coches. Sería algo parecido (más bien mucho mayor, pero bueno) a una tabla que relacionase directamente cada pieza con cada modelo de coche. La tabla tendría millones de registros (puede incluso que más de 100 millones, por decir algo)
    • Re:Tamaño? de adehoces (Puntos:1) Martes, 13 Noviembre de 2012, 12:21h
      • Re:Tamaño? de pobrecito hablador (Puntos:1) Martes, 13 Noviembre de 2012, 12:32h
        • Re:Tamaño? de sonda (Puntos:1) Viernes, 16 Noviembre de 2012, 16:03h
        • 1 respuesta por debajo de tu umbral de lectura actual.
    • Re:Tamaño? de jdavidls (Puntos:1) Martes, 13 Noviembre de 2012, 13:08h
    • 1 respuesta por debajo de tu umbral de lectura actual.
  • 9 respuestas por debajo de tu umbral de lectura actual.