SQL ¿Cuándo crear una nueva base de datos?

Question

Tengo tres aplicaciones diferentes, todas comparten el aspecto de membresía ASP.NET de la base de datos y casi definitivamente no compartirán nada más.

¿Debo tener una base de datos separada para cada una de las aplicaciones, o sería suficiente?

Todas las tablas de aplicación tienen el prefijo, por lo que no sería un problema en la integración. Aunque me preguntaba si habría algún problema de rendimiento, o si tener las tres aplicaciones compartiendo la misma base de datos sería un grave error.

Las aplicaciones en cuestión son tres aplicaciones web, el "sitio principal", un foro y un rastreador de errores. Me pregunto si esto es viable porque la integración podría ser más fácil si tuviera una sola base de datos. Por ejemplo, el rastreador de fallas registra las tablas de membresía asp.net en su conexión db, e incluso crea un usuario "administrador", donde el DB que en realidad se supone que contiene las tablas de membresía sería el "sitio principal".

Actualización: He añadido una recompensa a esta pregunta ya que las respuestas parecen tener opiniones bastante divididas sobre si debo usar o no múltiples bases de datos para diferentes aplicaciones que solo comparten proveedores de membresía.

Answer 1

Separar aplicaciones = bases de datos separadas, a menos que tenga que "exprimir" todo en una única base de datos (por ejemplo, en un servidor web compartido).

• bases de datos independientes se pueden sostener (y restaurados!) por separado.
• Se pueden distribuir bases de datos separadas en otros servidores cuando sea necesario.
• Las bases de datos separadas se pueden ajustar individualmente.

Answer 2

siempre he encontrado que sería mejor tener más bases de datos de manera que es más fácil:

1. Migrar a más servidores si es necesario
2. administrar la seguridad/acceso más fácil
3. más fácil (y más rápido) restaura y realiza copias de seguridad

De hecho, iría con cuatro bases de datos. Una base de datos de Membresía, y luego una para cada aplicación (si la membresía es verdaderamente compartida). Esto le permitirá bloquear la seguridad en todas las aplicaciones también.

Mirando su pregunta más cerca ... Usted dice que los datos "probablemente no se compartirán" ... ¿muchas de sus consultas se unirán a las mesas con la membresía? Si es así, podría ser más fácil si están en la misma base de datos. Sin embargo, si va con un enfoque más basado en la entidad, creo que aún sería mejor con múltiples bases de datos. Es posible que desee ver algo así como una base de datos LDAP u otro tipo de almacenamiento en caché para su base de datos de miembros para acelerar las cosas.

Answer 3

Sólo mi inclinación: a pesar de las tres aplicaciones podrían no compartir mucho (no todavía, de todos modos:? Pero lo que sucede cuando un mensaje del foro quiere hacer referencia a un informe de error), todos ellos pertenecen a la misma "sistema" por así decirlo.

Definitivamente pondría todas las tablas en una sola base de datos.

Answer 4

Debe utilizar la misma base de datos a menos que tenga una necesidad actual de ubicarlas en bases de datos separadas; SIN EMBARGO, cuando sea posible, debe diseñar su sistema para poder mover los datos a otra base de datos en caso de necesidad.

En la práctica, esto significa que debe mantener los procedimientos SQL trabajando la menor cantidad posible de datos, es decir, no tiene procesos almacenados en varios pasos que realizan muchas acciones por separado. Tener usps separados y llamar a cada uno desde el código.

Razones para utilizar bases de datos separadas:

1) datos no relacionados - Grupo de los datos que se relacionan entre sí las bases de datos - andonce ir más allá de una cierta complejidad, mira para separar bloques de datos relacionados en bases de datos separadas con el fin de simplificar.

2) Los datos que son de mayor importancia (por ejemplo, los datos personales) se deben separar para permitir mayores medidas de seguridad: p. seleccionando estos datos de los desarrolladores

3) o menor importancia (por ejemplo, Información de registro) - esto probablemente no necesita respaldo - y si es particularmente voluminoso, probablemente no desee que aumente el tiempo necesario para hacer una copia de seguridad del base de datos del sitio.

4) Utilizado por aplicaciones que viven en diferentes servidores en diferentes ubicaciones. Es obvio que desea ubicar los datos lo más cerca posible de la aplicación consumidora.

Sin saber realmente el tamaño y la escala de su sistema, es difícil dar una opinión completa, si es solo su propio sitio, un db puede funcionar por ahora; si es comercial, tendré 4 dbs de la palabra ir: Detalles de membresía, Foro, Bug Tracker y cosas relacionadas con MainSite.

Por lo tanto, en el código tendría un administrador de membresía que solo habla con la membresía db, A BugManager, A ForumManager y todo lo demás solo hablará con el db MainSite. No puedo pensar en ninguna razón por la que necesites que alguna de estas bases de datos se comuniquen entre sí.

Answer 5

En mi opinión, es mejor dividir la base de datos para aumentar la flexibilidad, la seguridad, la eficiencia y la escalabilidad.

En el futuro, si hay algún requisito adicional (nunca se sabe) que sea común para las tres aplicaciones, podría ser un poco difícil de mantener.

Por ejemplo: Secuencia de inicio de sesión/auditoría de usuario para sus 3 aplicaciones.

Answer 6

Puede parecer que estoy vagando un poco, pero ¿ha tenido en cuenta otra posibilidad, que es separar toda la funcionalidad de autenticación/membresía en una aplicación en sí misma?

De su descripción, parece que puede agregar otra aplicación en el futuro. Comenzaría a parecerse a una red de sitios, al igual que las aplicaciones web 37signals, las aplicaciones web de Google o las aplicaciones web de MSN.

Y por lo tanto, puede optar por un tipo de servicio Single-Sign-On/Connect. Esta única aplicación puede ofrecer métodos de autenticación a través de servicios web o cualquier otro mecanismo, tendrá su propia base de datos para que pueda ajustar, modificar, hacer copias de seguridad y moverse sin afectar las otras aplicaciones. Yo mismo he encontrado esta situación muchas veces y me encanta lo fácil que es compartir tu inicio de sesión de Google o Facebook entre las aplicaciones.

Tal vez lo estoy viendo desde una perspectiva un poco más alta que la tuya, lo siento si es el caso. Si esta no es una opción, puede mantener 4 bases de datos: 1 para cada aplicación y 1 para el proveedor de membresía, que tiene su propia conexión de cadena la mayor parte del tiempo.

Por supuesto, depende del tamaño de la huella de sus aplicaciones en el nivel de DB. 10 tablas por aplicación están bien, 150 tablas por aplicación harían que el DB fuera un poco feo para nosotros, siendo una preferencia personal.

Buena suerte con la opción que elija.

Answer 7

El membership framework permite la partición a través de múltiples aplicaciones, por lo que probablemente debería tener la siguiente configuración:

• base de datos de miembro
• Aplicación 1 Base de datos
• aplicación 2 Base de datos
• Aplicación 3 Base de datos

Luego, en cada una de las aplicaciones dat abases, cree sinónimos que apunten a las tablas de la base de datos de membresía para cuando necesite escribir sus propias consultas que accedan tanto a datos de aplicación como a datos de membresía. Los sinónimos son fáciles de mantener y le permiten cambiar dónde se encuentra la base de datos sin cambiar las dependencias de esas tablas, ya que los nombres de sinónimos no cambian.

La configuración de su aplicación en Web.config determinará cómo los datos se divide en la base de datos de miembros como se especifica una ApplicationName que debe ser diferente para cada aplicación.