2010-08-13 20 views
12

Think Design: ¡Tengo muchas aplicaciones que comparten la misma base de datos de usuarios! También se comparten otras tablas, como registros de actividad del usuario, compras, etc.¿Múltiple aplicación usando una base de datos?

1) De todos modos, mi pregunta es si tenía que hacer todas las aplicaciones, ¡solo usaría 1 base de datos para todo! ¿Tendría algún problema con la escalabilidad? O cualquier otro problema haciendo esto? ¿Es mejor tener 1 base de datos? ? O peor?

2) ¿O debería dejar que cada aplicación tenga su propia base de datos, y luego usar el servicio web para compartir las tablas comunes entre las aplicaciones?

+1

posible duplicado de [bases de datos individuales o múltiples] (http://stackoverflow.com/questions/1676552/single-or-multiple-databases) –

Respuesta

12

Cuantos más procesos tenga accediendo a un recurso compartido, más posibilidades tendrá de entrar en problemas de escalado/rendimiento y temporización.

Incluso si sus aplicaciones son pequeñas, recomendaría no hacerlo.

Probablemente la peor parte de todo este emprendimiento sería complejidad innecesaria que agregará a su conjunto de aplicaciones. Después de todo, la programación no es lineal, y el simple hecho de agregar una sola tabla para interactuar aumenta la complejidad general en más de un factor de uno.

Como mínimo, cree un servicio para interactuar con tablas de uso común y haga que sus aplicaciones realicen solicitudes a través del servicio.

Me identifico con su deseo de fusionar recursos en un lugar común, pero creo que en este caso se estará preparando para más dificultades en el futuro. Simplemente no creo que valga la pena.

En respuesta a sus ediciones ... Iría con la opción (2).

1

Las aplicaciones tienden a copiar las organizaciones que las crean. Si una base de datos tiene dos clientes, puede que se le pida que haga un cambio que podría romper las características que usa el otro cliente. Entonces, si la aplicación tiene un cliente pero varios esquemas distintos, es posible que desee colocarlos en una base de datos. Si la aplicación tiene muchos clientes, es posible que desee separarlos en diferentes bases de datos, incluso si el esquema es muy similar, si necesita admitir la posibilidad de evolucionar la aplicación para un usuario pero no para otro.

Blogger (la aplicación de Google) es un buen ejemplo. Ninguno de los clientes tiene influencia para solicitar una función solo para ellos, por lo que es muy probable que blogger coloque todo en un esquema/una base de datos.

+0

Blogger es sólo 1 gran base de datos? Btw SO es solo 1 gran base de datos ¿no? – 001

+0

Como dije inicialmente, "muy probablemente". El motor y el esquema de SO están en al menos 3 DB, uno para SO, uno para los viejos intercambios de pila, uno para los nuevos intercambios de pila, lo cual es lógico porque cada uno tiene un conjunto diferente de clientes y diferentes fuerzas que los hacen evolucionar. – MatthewMartin

8

No cree bases de datos separadas. Entonces tendrás una pesadilla para mantener y las cosas se desincronizarán. Las personas tendrán diferentes nombres e identificaciones en diferentes sistemas y será la peor pesadilla que hayas visto. Dups en un sistema coincidirá con una persona en otros creando problemas de informes. Solo escribir informes cuando intente hacer coincidir sistemas dispares será desagradable. Planifique la escalabilidad en su lugar. Aprenda a dividir los datos.

Si tiene varias aplicaciones que llegan a la misma base de datos, asegúrese de que la base de datos no mantenga la integridad de los datos, ¡no ninguna de las aplicaciones! Esto es fundamental ya que de lo contrario algunas aplicaciones podrían no saber para mantener ciertas cosas que otros necesitan y usted tendrá un desastre de integridad de datos para limpiar.Use restricciones PK y Fk reales, defina valores predeterminados, use los tipos de datos correctos para que no se puedan ingresar fechas inválidas, etc.

No permita que los desarrolladores cambien la estructura de la base de datos sin la aprobación de especialistas en bases de datos que saben qué otras aplicaciones pueden ser afectado por el cambio. Asegúrese de aprender a escribir código de rendimiento la primera vez, ya que afectará a otras aplicaciones con su código.

0

Algunas cosas serán genéricas en toda su empresa. Estas cosas incluyen Usuarios, Actividad del Usuario/registros de auditoría, etc. Estos pueden mantenerse fácilmente en una base de datos sin mucho esfuerzo.

Algunas cosas, aunque comparten una estructura común, deben separarse por algún motivo comercial. Dado que existe una razón declarada de que se trata de una necesidad comercial, no importa si es más fácil hacerlo en una base de datos o no: hacerlo en múltiples bases de datos.

Algunas cosas, sin embargo, caen en un área gris. Cada unidad tiene que tratar con un 'Cliente'. ¿Debería ser esto en una base de datos compartida? Puede haber otros también. Parece que estas cosas comparten tantas cosas en común, que realmente quieres almacenarlas en una base de datos.

De la experiencia personal: no. Las unidades de negocio separadas consideran cada una de estas cosas de manera diferente, y acomodar todas esas diferencias puede hacer que sus tablas sean una pesadilla de mantenimiento. Si desea un Data Warehouse donde pueda almacenar todos sus datos comerciales, puede ser una buena idea, pero los datos reales de las operaciones diarias deberían almacenarse probablemente en bases de datos separadas para mantener el uso lo más sencillo posible.

25

"O debo dejar que cada aplicación tiene su propia base de datos,"

En la década de 1950, cada aplicación tenía su propio conjunto privado de archivos. Después de una década más o menos, algunas personas inteligentes comenzaron a observar que ciertos elementos de datos dentro de esos "archivos privados de aplicaciones" eran en realidad información duplicada. Los nombres de los clientes estaban por todas partes, la información del punto de venta se había duplicado en todas partes, etc. etc.

La tecnología de bases de datos fue inventada por personas aún más inteligentes para resolver ese problema.

Y ahora en estos días, al hacer que las bases de datos sean "privadas de la aplicación", la generación de programadores de Internet está resucitando los mismos problemas que ya se resolvieron en la década de 1960.

Sólo un pensamiento mío, nada realmente importante.

"Aquellos que olvidan la historia, están condenados a repetirla". (Y que no es un pensamiento de la mina )

Cuestiones relacionadas