Base de datos para informacion masiva?

[digimikeh]

Hola amigos..

Tengo que diseñar un programa que será un cliente hecho en Qt C++, se debe conectar a una base de datos alojada en un servidor.

La situacion es que son 13 regiones, cada region tiene 15 modulos, y cada modulo utiliza 7 tablas independientes, entonces como verana son muchas muchas tablas (ese es mi concepto, posiblemente este equivocado), cada modulo ingresa informacion separada del resto, por eso pienso que son cientos de tablas...

Que se hace en este caso?

1) Crear una sola base de datos gigante que tenga 1365 tablas (13 x 15 x 7) y distinguirlas con un prefijo, ejemplo:  table_region0_modulo0_usuarios, table_region0_modulo0_direcciones, etc

2) Crear 13 bases de datos y 105 tablas por cada db..

3) Otra ...

All final, la idea es que cada modulo ejecute su cliente del programa, y se conecte al indice de su propio modulo y lea la informacion segun ese sufijo...


Como les he comentado, los registros de usuarios del modulo 0 no son los mismos que los del modulo 1.. por eso pense en crear muchas tablas..

Que hacer en este caso?
saludos y gracias.

[engel lex]

tendrías que pensar bien en la optimizacion segun el tipo de query, es decir, manejar 1300 tablas no es un problema, la cosa es internamente a ellas, incluso podría convenir DBs independiente para el caso que se quieran modularizar y separar los datos, tampoco es malo que hayan datos redundantes para disminuir el tiempo de busqueda (query cruzadas como join complejos), claro en caso que el tamaño y velocidad de acceso al disco sea suficiente, tampoco es malo que sean muy dispersos en caso que no tengas query complejas... asi mismo podrían ser una sola tabla con un campo para indicar la region (en caso que basicamente no tengas join) pero son casos puntuales...asi mismo recuerda que es posible hacer query entre diferentes bases de datos pero cuidado con el manejo porque te pueden dar mas velocidad o castrarte fatalmente

en pocas palabras, depende del tipo de query que se vayan a realizar, pero si, cada region por DB esta bien

[digimikeh]

hola Engel.

La idea es que en algun momento un modulo pueda obtener informacion de otro a modo de informacion o de traslado de activo.

No me ha quedado claro, dices que no seria problema crear esa cantidad de tablas ?

Como info adicional, estaré utilizando QODBC (ODBC).

El algoritmo del cliente es asi:
1) Un usuario que pertenece al modulo X abre el programa, selecciona su region y luego selecciona el modulo X.
2) El programa verifica si existen las tablas con el sufijo X en el servidor
3) Si no existen, las crea, si existen las lee y traspasa la informacion a las vistas.

Cada cliente hace esto, por lo que la creacion de las 1300 tablas seria un proceso automatico y rapido, aun asi, no se si es lo suficientemente práctico.

[engel lex]

no es bueno que el usuario de la DB al que tiene acceso el cliente tenga posibilidades mas allá de ver, insertar y actualizar, incluso solo borrar registros en casos especificos (aunque usualmente es mejor usar un campo para marcar el registro como eliminado para mantener una coherencia), mucho menos aun crear tablas... es mejor crear una estructura final desde el inicio

no, la cantidad de tablas no es problema

[Serapis]

Dices que son 13 regiones... pués crea 13 bases de datos.

Especialmente si así cada base de datos mantiene una estructura idéntica dentro y por tanto lo unico que diferencie una de otra sean los datos que almacenan.
No solo las tablas, si no las relaciones y las funciones serán idénticas, como digo solo cambiarán los datos. Es definitiva todas serian instancias de una misma.
Tan solo hará falta que el usuario/cliente al conectarse tenga la elección de elegir la BD, donde tiene acceso/está dado de alta.

Creas el esqueleto de una vacía... y se deja como plantilla, para cuando se requiera crear otra. Crear una BD, será entonces clonar esa BD vacía e introducir los datos previos que la especializan en una región.
Si la BD que sirve de esqueleto, es suficientemente simple y se crea rápido, incluso podría omitirse y crearse exprofeso al crear una nueva BD, si es compleja y tarda mucho, es preferible tener ese esqueleto, clonarla y privatizarla para esa la región, para la cual se crea...

Los usuarios deberían poder acceder a su BD de forma directa (salvo en el registro y el login si está todo unificado), para no penalizarles con un retraso por cada petición que dirima a qué BD se dirige, pués para eso está el login...
Sin embargo, para la administración de las BD, se precisarán que determinadas funciones incluyan un parámetro que señale a cual de las BD va dirigida la petición.

Considera todo el conjunto como un colegio... la administración de la BD, debe ser como la administración del colegio, y cada BD, debe entenderse como una clase... todas las clases tienen la misma estructura (se componene de lo mismo), alumnos, profesores, asignatura, horarios... pero esos datos son distintos en cada clase.
Un alumno al incscribirse en una asignatura/clase, debe dirigirse a la administración, una vez admitido, simplemente acude a las clases directamente.
Cualquier duda posterior que tengas, intenta verlo reflejado en el esquema del colegio que es "well-known"... para sacar tus propias conclusiones.

[digimikeh]

gracias por las respuestas amigos,
me ha quedado mas claro ahora.. saludos

[WHK]

13 regiones, cada region tiene 15 modulos, y cada modulo utiliza 7 tablas independientes

Pues fácil, haces 7 tablas con sus columnas, le agregas una columna adicional relacional con el id del módulo, una tabla con los módulos, una tabla con las regiones y una tabla intermediaria relacional entre id de módulo y id de región. En total tendrás sólo 10 tablas.

Entonces, para saber a que módulo pertenece un registro solo le haces un where al id de módulo, y para saber a que region le pertenece un registro haces un inner join y le haces un where al id de región. De esa manera todos los registros de todos los módulos de todas las regiones estarán en esas mismas 7 tablas.

Si después necesitas obtener datos analíticos como por ejemplo cuantos registros existen por cada región tendrás que crear tablas desnormalizadas, o sea con datos planos y duplicados con contadores fijos para no tener que estar contando todo cada ves que quieras obtener un informe.

No te recomiendo hacer múltiples bases de datos, en ese caso podrías hacer particionamiento de datos sobre la base de datos (sufijos) pero tampoco te lo recomiendo ya que tu estructura no es tan grande ni compleja como para hacer esa separación, a demás tendrás que manejar permisos, optimización, administración multiplicado por tus regiones, si tu app es una sola y maneja múltiples grupos de datos puedes asociarlos dentro de una misma base de datos siempre y cuando sean parte de un mismo proyecto independiente de cuantas capas tenga.

Mira, acá te lo explico mejor: https://voca.ro/jQJ4QiDDfkc

Saludos.

[digimikeh]

Eso de crear una base de datos por region me parece que seria mas facil para mi en este caso, ya que la relacion que hay entre region y region es muy poca, es casi estadistica... es verdad que pude haberlo hecho inclusive con sqlite, pero justamente esto no me permitiria hacer una estadistica entre region..

voy a revisar el audio! slaudos.
gracias.

[WHK]

Y cuando necesites modificar la base de datos las modificarás una por una? te asegurarás que todos los cambios queden iguales en todas las bases de datos? usarás migraciones de cambios?, harás respaldos por separado uno por uno? , separarás los accesos?, vas a tener que multiplicar tus esfuerzos cada ves que quieras hacer algo sobre la base de datos y organizarlas.

[digimikeh]

bueno, definitivamente tengo que evaluar todo esto..