Diseño de la Base de Datos

[[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.