Diseño de la Base de Datos

[[gluglu]]

Estimados compañeros del foro :

Después de la pregunta que hice ayer acerca de si se puede hacer un JOIN sobre dos tablas de bases de datos diferentes (recordatorio: utilizo InterBase 7.5) me surge la siguiente pregunta existencial :

Estoy programando una aplicación que va a trabajar en modo cliente/servidor, de gestión hotelera, en donde van a existir diferentes puntos de venta (hoteles), cada cual no debe de ver los datos del otro (ni le importan tampoco) (reservas), pero en donde van a existir una serie de ficheros maestros comunes para todos (Clientes, tarifas, agencias,etc.) y a los cuales todos van a acceder.

Inicialmente he pensado en utilizar una base de datos para los datos comunes, y bases de datos individuales para cada uno de los hoteles.

Ahora bien, si no puedo realizar las consultas posteriores con relativa comodidad (p.ej. mediante la utilización de JOIN), debería ser más adecuado tener una "mega"-base de datos que contenga no solo los ficheros maestros, sino también los datos individuales de cada hotel?

El número de registros que por ejemplo puede contener cada hotel puede llegar al millón o más. Eso significaría que si la base de datos fuera común podría tener un tamaño más que considerable.

Si trabajara con bases de datos individuales, qué comodidad tendría al ver por ejemplo habitaciones disponibles en todos los hoteles, o por regiones, o por tipo? Sería más fácil de nuevo teniendo todos los registros en la misma y única base de datos?

Quiero aclarar que procedo del Clipper y evidentemente era incocebible en el Clipper tener bases de datos de millones de registros, por lo cual trabajaba con diferentes estructuras de directorios y bases de datos particionadas e individuales.

Una vez más deseo agradeceros a todos la ayuda que prestais mediante este foro.

Un saludos a todos.

[Coco]

Alguna vez tuve un problema similar al que cuentas y lo solucione agregando un campo mas en la base de datos central que indicaba para cada registro cual fue su ultima fecha de modificacion y opcionalmente quien la modifico.

Luego, cada cierto lapso de tiempo se replicaba la informacion a la base local de cada aplicacion, pero solo lo hacia con aquellos registros que habian sido modificados desde la ultima replicacion anterior.

En tu caso podrias guardar los datos de los clientes en la base centralizada, datos que por lo que pienso no se modifican continuamente, y por lo que la replicacion no demandaria mucho espacio. Luego replicas los registros modificados a tu base.

Espero que te sirva. 1Salu2.

[[gluglu]]

No me gusta mucha esa solución, ya que evidentemente se incrementa el tráfico en la red de manera innecesaria para la replicación. Por eso precisamente me baso en un diseño cliente/servidor.

Pero una pregunta por ejemplo concreta : Quiero ver todas las habitaciones disponibles de todos los hoteles de España de una cadena. Si la cadena hotelera dispone de 50 hoteles en España, y tengo 50 bases de datos individuales (una para cada hotel), necesitaré hacer 50 consultas individualizadas para después uirlas en un solo resultado.

Si tuviera una única base de datos donde mediante un campo "NumHotel" diferenciara las reservas de cada hotel, con un único SQL podría fácilmente obtener el resultado de mi consulta, no?

La pregunta clave aquí es si esa "mega" base de datos que contenga toda la información de todos los hoteles es razonable, factible, mantenible, segura y eficiente ?

Insisto una vez más, en Clipper por supuesto que no lo era. No tenía ningún sentido (más bien era una irresponsabilidad por parte del programador) tener una base de datos (tabla en Delphi, claro ...) con varios Gigas de tamaño. La corrupción de índices podía ser frecuente y regenerar indices con esos tamaños se perfilaba como simplemente "imposible!".

De nuevo, saludos y gracias por vuestras ayudas.

[Coco]

Desde ya que si utilizas una unica base central para todo el sistema y teniendo en cuenta la cantidad de registros que tienes que manejar el resultado puede no ser el mejor. O sea, creo que puede ser factible y segura, pero no creo que pueda ser eficiente y mantenible.

Ten en cuenta tambien que las consultas que ejecutes te pueden afectar el trafico de la red, y sobre todo el tiempo que puede demorarse en devolverte los resultados.

En cuanto a tener 50 bases diferentes creo que es la solucion menos factible, piensa que puede suceder si en el futuro quieres agregar un nuevo hotel, o lo que es mas probable, que la conexion con alguno de los hoteles se puede caer , ademas ni hablar del trafico en la red, no?

Saludos

[[gluglu]]

Pues si no es interesante ni tener 50 (o más), ni tampoco una única, entonces cual sería la opción más razonable ?

Respecto a añadir un nuevo hotel no sería problema alguno según tenía pensado. Si tengo una tabla centralizada con los códigos y nombres de los hoteles, en donde además se indica en qué lugar (directorio, servidor, direcciones IP, etcétera) están los datos particulares de ese hotel, pues bastaría que el administrador del sistema añada un registro a esa base de datos de hoteles y establezca la base de datos individual con sus tablas correspondientes en el hotel nuevo a instalar (bien en un servidor centralizado, regional, o incluso local)

Como la tabla de los hoteles que existen precisamente es única y centralizada, los demás hoteles estarán informados (si así se decide) de qué otros hoteles existen, y en caso de darle acceso a datos ajenos, donde se encuentran esos datos.

Toda esta cuestión se me plantea estando ya un poco avanzado en el diseño de la base de datos y sus tablas maestras, y precisamente ahora me encuentro con la duda de no saber cual es la mejor opción, y antes de continuar debería decidir.

Y también respecto a caerse la red, si cae uno de los hoteles, esto no afectará a los demás ya que los datos propios no están en la misma base de datos de los demás (independientemente del lugar donde decidamos "ubicar" esas bases de datos individuales).

Saludos

[Neftali [Germán.Estévez]]

Nunca se puede generalizar, pero yo me inclino por una única Base de Datos. Depende en gran medida de lo que vayas a necesitar. Cuanta más compartición de datos exista entre las diferentes entidades (hoteles) más a cuenta te saldrá la solución de la Base de Datos única. Si hay poca cosa en común entre ellos tal vez la otra.

Piensa que no sólo es compartir determinadas tablas; En nuestro caso (que en diseño es similar) luego aparecen personas que deben tener acceso a diferentes Bases de Datos. Por decirte algo, hay un "Responsable de provincia" que tiene que tener acceso a todos los datos de los hoteles de su provincia. Luego hay una persona que debe acceder a datos estadísticos (de todas las entidades),... y así podría seguir y no acabaría.

[[gluglu]]

Claro que sí !

No sólo van a existir usuarios que deben de acceder sólo a los datos propios, sino que siempre habrá usuarios "supervisores" (o como dices "responsables" de zona, etc) que tengan que tener acceso a todos los datos.

Incluso un recepcionista normal, en caso de que su propio hotel esté completo debe de poder ofertar al cliente que p.ej. llame por teléfono, la disponibilidad en otro hotel de la zona.

Esa es precisamente mi duda ! De nuevo digo que en Clipper era impensable tener todos esos datos en una única base de datos. Pero concretamente ahora cuando estoy avanzando en mi diseño, denoto que tener varias bases de datos separadas me produce más complicaciones que tenerlas juntas en una única.

Por supuesto, ahora mismo estoy utilizando InterBase que me parece bastante buena y potente, pero en cualquier momento se puede actualizar a bases de datos mucho más potentes (Oracle ...) que soporten mucha mayor cantidad de datos. Todo ello dependerá de la escala y tamaño del cliente (hotel(es)), y de la inversión económica que quieran hacer en los diferentes elementos.

A nivel de diseño me toca a mí decidir de momento como enfocar la estructura dentro del programa. Y estoy tendiendo a pensar que una única base de datos me ofrece mayores ventajas que no siendo única.

Saludos !

[Neftali [Germán.Estévez]]

Empezado por gluglu

...Pero concretamente ahora cuando estoy avanzando en mi diseño, denoto que tener varias bases de datos separadas me produce más complicaciones que tenerlas juntas en una única.

...pero en cualquier momento se puede actualizar a bases de datos mucho más potentes (Oracle ...) que soporten mucha mayor cantidad de datos...

...Y estoy tendiendo a pensar que una única base de datos me ofrece mayores ventajas que no siendo única...

Es justo lo que pienso yo y cómo lo hemos enfocado nosotros; En nuestro caso en el punto 2 ya hemos "saltado" a SQL Server.