Multiples bases vs Multiples tablas

[Chico3001]

Hola, estoy desarrollando un portal con multiples aplicaciones, todos ingresan en la misma pagina y segun sus modulos contratados se despliegan diferentes opciones

Pero me surgio la duda, que sera mas eficiente y seguro? mantener distintas bases de datos (una para cada aplicacion) o tener todos los datos en la misma base pero distintas tablas

Con el acercamiento de distintas bases tendria que manejar una base maestra que mantenga usuarios y contraseñas de las bases esclavas, pero me permite individualizar los datos de cada usuario y asi tener una mayor facillidad a la hora de hacer respaldos y tambien asegura que unos no pueden ver datos de otros

En cambio con el acercamiento de multiples tablas tendria los datos compartidos en una unica base, el manejo de los datos seria mas simple pero los respaldos serian mas complejos y existe la posibilidad de que un usuario pueda ver datos de otro

Como atacarian este problema para lograr una buena comunion entre facilidad de acceso y seguridad?

[quimfv]

No lo estas enfocando bien.

...asi tener una mayor facillidad a la hora de hacer respaldos ...

No veo esa mejora por ningun lado, tendràs mayor facilidad para los respaldos de una de las opciones (aplicacion-bbdd) pero no para los datos de un usuario (usuario bbdd-maesta + n bbdd segun sus opciones)

...tambien asegura que unos no pueden ver datos de otros...

Tampoco veo esa mejora, ya que si un usuario tiene acceso a la bbdd de la opción A sus datos estaran juntos con los de los demas usuarios que tengan acceso a la opcion A, luego, segun tu razonamiento, podria ver los datos de los demas usuarios con la opción A.

...existe la posibilidad de que un usuario pueda ver datos de otro...

Por el punto anterior tampoco se daria este, el control de que cada usuario vea sus datos no debe depender de que esten en bbdd didstintas ni en tablas distintas...

Solo conseguirias un plus de seguridad con una bbdd por usuario, pero eso es totalmente desaconsejable des del punto de vista de mantenimiento, imagina que tienes 100 usuarios y tienes que cambiar algo de la estructura de la bbdd...

Es muy facil que distintas opciones compartan recursos, tu ya as identificado uno la lista de usuarios y opciones de estos, luego la relacion no es ni de aplicacion-bbdd ni aplicacion-tabla. Debes plantertelo como un todo que comparte recursos y crear las tablas que necesites y no repetir aquellas que ya se hayan creado. Este ultimo punto es crucial paramantener la coherencia de todo el sistema, el mantenimiento de los recursos compartidos entre aplicaciones y/o usuarios debe hacerse en un solo lugar, por que qualquier error podria dejar el sistema inconsistente....

Yo te diria una sola base de datos pero claro con lo que nos cuentas es un poco arriesgado, ya que no sabemos que vas a hacer solo puedo rebatir tus argumentos.

[Chico3001]

La idea es tener una web de servicios en la nube, donde los clientes pueden ir administrando sus datos, como clientes, ingresos, egresos, facturacion, produccion, inventarios, etc...

Cada cliente puede ir contratando uno o varios modulos y por lo mismo no todos los clientes tendran los mismos modulos

Como ya bien dijiste lo ideal seria tener una base por cliente, pero a la hora de hacer una actualizacion seria un desastre, se tendrian que actualizar varias bases al mismo tiempo, aunque es un poco mas segura ya que si un cliente tiene un problema no afecta a ningun otro cliente

En cambio con una base compartida el mantenimiento es simple, pero si hay algun problema se afectara a toda la base, (por problema me refiero a algun hackeo, algun empleado que quiera borrar datos o algun error en el codigo, etc)

Esta pregunta me ha rondado la cabeza varios dias, pero sinceramente mi experiencia en un sistema asi es muy basica, por eso se me ocurrio preguntar x aqui, si alguien maneja ese tipo de datos y como ataca este problema...

[quimfv]

Yo NO he dicho que sea ideal tener una base por cliente, he dicho que es la unica opción que tedaría un plus de seguridad, y eso solo siguiendo tu razonamiento, pero nunca que fuese ideal.

Imagina las bbdd que tendrían que tener los bancos si eso fuese lo ideal!!!! Y ellos teoricamente lo podrian pagar...

Si la aplicación esta bien hecha el empleado que quiera p..t..ar solo lo deberia poder hacer sobre los datos que tenga acceso no sobre los de los demas...

No todos los fallos que afecten a un cliente tienen por que afectar a los otros aun que esten en la misma bbdd, y obviamente habra fallos que afectaran a todos... pero si esos son por errores de estructura a la corta o a la larga se daran en todas las copias de la misma estructura tengas ... y si son de servidor excepto que tengas las bases de cada clente en servidores distintos tambien afectaran a todos esten o no en bases distintas...

[minkweb]

Yo también ando con este dilema, obvio es mucho más cómodo 1 sola base de datos desde el punto de vista de actualizaciones (Aunque también puedes correr procesos que modifiquen todas las bases de datos al mismo tiempo y ya), pero lo que hace pensar, es que si es una sola base de datos donde se maneja facturación y cosas similares, tarde o temprano las tablas van a empezar a fallar en velocidad con las consultas, tocara invertir más dinero en servidores, usar algo como memcached y balanceo de carga del servidor mysql (disculpen si me equivoco pero balancear las cargas de un servidor mysql no implica duplicar los datos?)

Teniendo eso en cuenta…

¿Mejor varias bases de datos o una base de datos y a largo plazo invertir más dinero en recursos de servidor?

Edit:solo para agregar, si no estoy mal wordpress, phpbb2, blogspot y este tipo de aplicaciones usan una base de datos por cliente

[quimfv]

Si todo se hace muy grande y hay recursos suficientes obviamente el numero de opciones aumenta, incluso usar motores de bases de datos de pago que tambien ofrecen mas y mejores recursos para conseguir un mejor balanceo de los datos.

Una cosa son aplicaciones como las que mencionas donde un usuario crea su base de datos para hacer una cosa concreta y la instala en su servidor...

Si se trata de crear una aplicacion unicliente y autoadminstrada obviamente tendrà una bbdd para cada cliente eso seria una cosa

Si se trata de crear una aplicacion que gestiona servicios a muchos clientes, adminstrada de forma central seria otra cosa distinta y la soluciones no serian las mismas.

Creo que el ejemplo de los bancos es bueno en este caso, yo puedo administrar mis cuentas via web, hacer tranferencias etc. con total seguridad de que no tocare nada que no sea mio apesar de que mis datos estan en una sola base de datos, o mejor seguro que estan en una nube de bases de datos organizada no por cliente sino por necesidades del banco o del sistema... obviamente usaran n servidores distintos ...

Si me instalo un wordpress version X y los desarroladores de wordpress crean la version X+1 es decisión mia si la voy a usar o no y si me compensa o no el trabajo de migrar los datos...

(disculpen si me equivoco pero balancear las cargas de un servidor mysql no implica duplicar los datos?)

No te equivocas, ni duplicar datos ni duplicar estructuras....ni separar por bbdd ni separar por tablas o todo a la vez, quiero decir que no hay una solución generica. Una solucion optima puede dejar de serlo si las previsones de crecimiento no se cumplen, tanto por exceso como por defecto. Si hago un diseño optimo para tarabajar con miles de millones de datos y acabo trabajando con unos pocos miles esa solucion seguramente no será la mejor, y exactamente lo mismo si se da la situación inversa.

[minkweb]

Bueno con respecto a..

Una cosa son aplicaciones como las que mencionas donde un usuario crea su base de datos para hacer una cosa concreta y la instala en su servidor

Me refería a los servicios de wordpress o blogger, estos se contratan en los servidores de ellos y me imagino que cuando lo creas te crea una base de datos y una carpeta para ti.

Con respecto a dar una solución genérica, pues con permiso te plantaría una preguntaría más específica y disculpa si es redundante a lo que ya nos explicaste.

Digamos que se tiene una aplicación para empresas, cada empresa tiene sus empleados, clientes y proveedores, ósea que se tiene 1 grupo que son las empresas y 3 subgrupos que son empleados, clientes y proveedores, va con contabilidad y todos los juguetes, esperando unas 10.000 empresas registradas, teniendo en cuenta que a lo largo de 4 años existirá mucha data, según tu experiencia ¿optarías por una sola base de datos bien relacionada o base de datos por empresa?

[Chico3001]

Iniciado por minkweb

Digamos que se tiene una aplicación para empresas, cada empresa tiene sus empleados, clientes y proveedores, ósea que se tiene 1 grupo que son las empresas y 3 subgrupos que son empleados, clientes y proveedores, va con contabilidad y todos los juguetes, esperando unas 10.000 empresas registradas, teniendo en cuenta que a lo largo de 4 años existirá mucha data, según tu experiencia ¿optarías por una sola base de datos bien relacionada o base de datos por empresa?

Exactamente esa es mi duda....

[ben10]

Depende si las consultas van a estar utilizando todos los campos relacionados entre si. Si algunos campos tiene relacion y otros no,los puedes agrupar y crear dos o mas bases de datos.

[quimfv]

Incluso en los programas de contabilidad digamos tradicionales existe la posibilidad de llevar las cuentas de varias empresas.

Tu como proveedor del servicio que vas a hacer?

1. Ofreces el host+software para la autogestion empresarial.
2. Ademas del punto anterior, ofreces servicios de gestoria (fiscal, laboral...) a todas las empresas registradas.

Ceo que ahi habria la gran diferencia.

Insisto con el ejemplo del banco, un banco tambien se podria plantear tener los datos de los clientes en bbdd distintas pero luego no podria, o se dificultaria, la realización de su parte del negocio. (El ejemplo es forzado).

Otro ejemplo seria facebook tambien te das de alta como usuario pero tus datos se guardan junto con los de los otros usuarios puesto que ofrecen servicios que si no fuera así no se podrian prestar.

No estoy diciendo que los bancos o facebook esten trabajando con una sola bbdd. Pero si que sus bbdd trabajan como si fueran una sola.

No hace falta recordar que SQL permite relacionar tablas de distintas bases de datos...

En definitiva si los clientes lo que hacen es comprar una aplicación (on line) que van a gestionar independientemente, quizas serviria un modelo bbdd/cliente, con el consiguiente coste en el momento de las actualizaciones, pero como se ha dicho eso tambien se puede automatizar.

Si los datos de todos los clientes van a taner una gestion centralizada seria mejor organizalos de manera que lo facilite. Con el coste de implementar una buena gestion de usuarios que de a estos la "ilusión" de estar trabajando con un su propia base de datos.