Es buena practicar crear varias bases de datos y relacionarlas

[Montes28]

Hola amigos,

Es buena practica crear varias bases de datos y relacionarlas, me refiero a que en una base de datos tenga la tabla usuarios y en otra bases de datos tenga por ejemplo historia laboral y en otra base de datos tenga gastos.

[Libras]

y como para que quieres tenerlas en ese esquema?

[Montes28]

Libras gracias por responder,

Es un debate que tengo con un colega, El opina que las entidades mas fuertes del negocio o sea por ejemplo Usuarios, clientes, este en una base de datos y por ejemplo las facturas, historial laboral en otra base de datos;
y yo opino que debe de ser una sola base de datos y utilizar varias relaciones(oseas tablas).

[Libras]

En ese caso lo mejor es tener todo en una sola base de datos, cuales son los argumentos para tenerlas en bases de datos separadas? Digo no se cuales sean los argumentos por los cuales debaten que es mejor tenerlas en una sola o separadas....

[Montes28]

El lo enfoca a las relaciones, que una tabla no puede tener mas de una relacion mucho a muchos y que el join tiene que llegar por el camino mas corto.

[Libras]

y que tienen que ver las relaciones entre las tablas, una tabla puede tener mas de una relacion uno a muchos siempre y cuando sea justificable, y en cuanto a los join, si se tiene que buscar el camino mas corto, pero eso se logra haciendo un buen query, no tiene nada que ver el numero de joins

[Montes28]

Se charlo la siguiente situación:

Un usuario hace parte de un area_administrativa(esto para fines operativos)
Y Un usuario hace parte de muchas areas para el tema de que le paguen

El propone que ahi serian muchas relaciones que seria mejor pasar el area administrativa a otra base y las areas para dinero a otra base.

yo lo propuse como relaciones en una sola base de datos y ya dependiendo de lo que se necesita consultar pues obvio se consultas las tablas involucradas.

[Libras]

Asi es dependiendo lo que quieras consultar serian las tablas que utilizarias, no le veo razon para tener 2 bases, ahora los 2 son desarrolladores vdd??

[Montes28]

los dos desarrollamos

Pero yo tengo un poco mas de experiencia con bases de datos.

[Libras]

Se ve, esas ideas del desarrollador de que no es bueno tener muchas tablas, muchas relaciones etc, digo para optimizar eso existen indices, estadisticas, subqueries, vistas, etc etc, pero bueno

[iislas]

Habria que conocer el contexto total, en SQL SERVER existe un servicio para concentrar los CATALOGOS, asi por ejemplo, el CATALOGO de empleados, deberia estar en MASTER DATA SERVICES, ya que un empleado de una empresa que agrupa varias empresas, siempre seria el mismo USUARIO en todas las empresas del grupo, ¿me explique?, PRODUCTOS, PROVEEDORES, etc, etc, etc.

[gnzsoloyo]

Usualmente, y hablando desde la perspectiva del Analisis de Sistemas, si existe dependencia funcional (esencialmente dependencia definida por FK) entre las tablas, se trata de componentes del mismo esquema o BBDD.
Pero si se trata de dependencias que pueden ser alimentadas por interfaces o vistas, estas NO componen el mismo esquema.

Normalmente, en las clases de BBDD en la universidad, el titular de la cátedra solía explicarnos que si el esquema de datos de un área de gestion no comparte completamente datos con otra área, esto requiere restricciones de acceso que son administradas por permisos a esquemas diferentes. En pocas palabras, no es correcto poner los datos comerciales (Facturacion, precios, stock) en el mismo esquema de gestion administrativa interna (Usuario, Accesos, Departamentos, Gerencias).
¿Se entiende?
Mientras mas desagregacion de áreas y responsabilidades tienes en la empresa, mas desagregacion debes aplicar al diseño de diferentes BBDD.

En mi experiencia práctica con empresas grandes, TODO acceso a datos que no sean específicos de un área determinada, deben ser intermediados por servicios de Middleware, o colocados en esquemas separados de donde sólo se CONSULTAN. DE este modo el acceso a datos es administrable de una forma eficiente y efectiva.

[iislas]

Completamente de acuerdo, asi se cumple con las reglas del modelado de datos.

[X_fran]

Por escribir algo, porque todo está dicho, abogo por mantener varios esquemas por supuesto en una misma base de datos, facilita la gesión de la seguridad !!!

[mortiprogramador]

Saludo

Creo que se han dado distintos puntos a priori.
Falta conocer más respecto al ámbito en el cual
están manejando la aplicación.

Sería bueno saber si la aplicación es a nivel interno
(intranet o similares) o interno (hosting, cloud, etc)

Esto porque por ej, en el caso de servicios hosting
en algunos proveedores hay limitantes de uso de bds,
e incluso tablas.

Igualmente, saber cuál motor de base de datos se está usando,
porque algunos manejan si o si manejo de dbs con un solo esquema (aunque en otros motores los esquemas vienen a ser las mismas dbs),
y otros si permiten manejar varios esquemas dentro de una db.

Teniendo esto en mente, si el motor permite crear
esquemas dentro de una bd y se tiene clara la segmentación
entre aplicaciones que manejarán los mismos, podría ser la mejor opción.

Si por otra parte, el motor solo permite crear bds sin manejar esquemas
internos, lo que se podría hacer es simplemente manejar esta db y
temas como permisos de aplicaciones o demás controlarlos con la creación
de distintos usuarios en la bd con diferentes niveles de acceso (SELECT, INSERT, etc) dependiendo de cada necesidad.

Pero sin importar la decisión que se tome, lo que no varía es la implementación
de los querys, que sin importar si se manejan o no esquemas van a entrar en juego, pero claramente, si se tienen que tener en cuenta los esquemas
a la hora de crear el query para no apuntar a sitios incorrectos si estos son implementados.