Base de datos por aplicación VS Una gran base de datos para todas las aplicaciones

Estoy diseñando algunas aplicaciones que compartirán 2 o 3 tablas de bases de datos y todas las otras tablas serán independientes de cada aplicación. Las bases de datos compartidas contienen principalmente información del usuario, y puede darse el caso donde otras tablas necesitan ser compartidas, pero ese es mi instinto para hablar.Base de datos por aplicación VS Una gran base de datos para todas las aplicaciones

Estoy inclinado sobre la base de datos para toda la solución de aplicaciones, ya que quiero tener la integridad de referencia, y no voy a tener que seguir la misma información al día en cada una de las bases de datos, pero probablemente voy para finalizar con una base de datos de más de 100 tablas donde solo grupos de diez tablas tendrán información relacionada.

La base de datos por enfoque de aplicación me ayuda a mantener todo más organizado, pero no sé cómo mantener las tablas relacionadas en todas las bases de datos actualizadas.

Entonces, la pregunta básica es: ¿cuál de los dos enfoques recomienda?

Gracias,

Jorge Vargas.

Edición 1:

Cuando hablo de no ser capaz de tener la integridad referencial, es porque no hay manera de tener claves externas de las tablas cuando esas tablas se encuentran en diferentes bases de datos, y por lo menos una de las mesas por la aplicación necesitará una clave externa para una de las tablas compartidas.

Edición 2:

Enlaces a preguntas relacionadas:

Sólo el segundo tiene una respuesta aceptada. Todavía no he decidido qué hacer.

Respuesta:

he decidido ir con una base de datos por aplicación con referencias entre bases de datos a una base de datos compartida, la adición de puntos de vista para cada base de datos que imitan las tablas de la base de datos compartida, y el uso de NHibernate como mi ORM Como el sistema de membresía, usaré el asp.net.

También usaré disparadores y eliminaciones lógicas para tratar de mantener al mínimo el número de ID que tendré volando alrededor de livin 'la vida loca sin un padre. El esfuerzo de desarrollo necesario para mantener sincronizadas las bases de datos es demasiado y el resultado es muy poco (como todos han señalado). Por lo tanto, preferiría abrirme camino a través de los registros huérfanos.

Dado que el uso de un ORM y vistas fue sugerido por primera vez por svinto, obtiene la respuesta correcta.

Gracias a todos por ayudarme con esta difícil decisión.

Fuente

2010-05-10 Jorge Vargas

Depende y sus opciones son un poco diferentes dependiendo de la base de datos y los marcos que está utilizando. Recomiendo usar algún tipo de ORM y de esa manera no necesitas molestarte tanto. De todos modos, probablemente podría poner cada aplicación en su propio esquema en la base de datos y luego hacer referencia a las tablas compartidas por schemaname.nombre de tabla o crear vistas en cada esquema de aplicación que es solo SELECT * FROM schemaname.tablename y luego código contra esa vista.

Fuente

2010-05-10 16:41:15 svinto

¿Qué quiere decir con que no necesitaré molestarme si estoy usando algún tipo de ORM? ¿Cómo puede un ORM ayudarme a resolver mi problema? Si pudiera dar algunos consejos sobre esto, realmente lo agradecería. Me gusta el enfoque de vista que mencionas, pero aún tendré el problema de integridad referencial. Voy a tener que intentarlo para ver cómo funciona. –

Señale sus claves externas a las vistas y con la integridad referencial está de acuerdo. Si usa un ORM, codifica eso en lugar de las tablas, por lo que no necesita preocuparse por todo excepto cuando crea tablas nuevas o establece índices, claves, etcétera. – svinto

¿Es posible señalar claves externas a vistas con MS SQL Server 2005? Esta respuesta http://stackoverflow.com/questions/447122/can-i-have-a-foreign-key-referencing-a-column-in-a-view-in-sql-server/447151#447151 dice que no es posible Trataré de hacerlo con el código SQL ya que el diseñador solo me mostró las tablas y te avisaré si puedo hacer que esto funcione. Gracias. –

Una base de datos para todas las aplicaciones, en mi opinión. Los datos se almacenarán una vez sin repetición.

Con otro enfoque que terminaría replicar y en mi opinión cuando se inicia la replicación que traerá su propio dolor de cabeza y los datos saldría de sincronización demasiado

Fuente

2010-05-10 16:44:03 Lisa

Sí, ese es mi principal problema con la base de datos por enfoque de la aplicación. Probablemente podría resolver esto si tuviera algo así como una "base de datos principal" que tenga los datos compartidos con algunos disparadores para actualizar las diferentes bases de datos, y la creación de una aplicación de administración para administrar esa "base de datos principal". –

Me gusta esto, DB principal, ser una fuente principal de tabla "común" sería casi ideal si está bien con desajustes temporales de datos entre aplicaciones debido a retrasos en la replicación. – bobah

Lisa: ¿y la seguridad? Una aplicación puede, si no se atiende, acceder al contenido de otra aplicación. –

Ni modo parece ideal

Creo que se debería considerar no hacer referencias en la capa de la base de datos para las relaciones entre aplicaciones, y hacerlas en la capa de aplicación. Eso le permitiría dividirlo en una base de datos por aplicación.

Estoy trabajando en una aplicación con más de 100 tablas. Los tengo en una base de datos, y están separados por prefijos; cada tabla tiene un prefijo para el módulo al que pertenece. Luego construí una capa sobre las funciones de la base de datos para usar estos grupos personalizados. También estoy creando un administrador de datos, que aprovecha estos grupos de tablas y hace que editar datos sea muy fácil.

Fuente

2010-05-10 16:44:59 marianboda

¡Ja! Nunca vi venir esa respuesta. Gracias por compartir su experiencia de la vida real. También voy a construir una aplicación de administración de datos, y al principio solo necesitará acceder a las tablas compartidas (información del usuario). Ahora que pienso en esto, también debería haber mencionado esto en la pregunta. De todos modos, en esta aplicación, el administrador elegirá qué usuarios tienen acceso a qué aplicación. Esa es otra razón por la que me inclino por el único enfoque de base de datos. –

No existen reglas estrictas para elegir una sobre la otra.

Múltiples bases de datos proporcionan modularidad. En lo que respecta a la sincronización en múltiples bases de datos, uno puede usar el concepto de servidores vinculados y sus vistas, y también puede obtener las ventajas de la base de datos integrada (acceso unificado).

Además, mantener múltiples bases de datos puede ayudar a una mejor administración de la seguridad, los datos, la copia de seguridad & restauración, duplicación, escalado, etc.

Mi 2cents.

Fuente

2010-05-10 16:51:39

Sí, lo sé. ¡Por eso estoy pidiendo las opiniones de los expertos! La mayor cantidad de comentarios que pueda obtener me ayudarán a obtener la opinión más informada. Usted es la tercera persona que me ha contado más beneficios de múltiples bases de datos que el enfoque de base de datos única. Gracias. –

El enfoque más apropiado desde el punto de vista de escalabilidad y mantenimiento sería hacer que el subconjunto de tablas "compartidas/comunes" sea autosuficiente y ponerlo en la base de datos "comunes", para todos los demás tiene 1 db por aplicación de por lógica ámbito de aplicación (lógica de negocio determinado) y mantener esta estructura siempre

esto facilitará los procedimientos de puesta en marcha/desmantelamiento/reubicación/requieren muy poco mantenimiento de planificación y ejecución de su software (usted sabrá exactamente qué dos afectados DBs (bienes comunes + app_specific) están involucrados si usted sabe qué aplicación va a tocar y viceversa.

Fuente

2010-05-10 16:52:54 bobah

Esas son cosas buenas para tener en cuenta. Cualquier cosa que ayude a mantener el mantenimiento más fácil es algo a considerar con fuerza, y saber qué tablas voy a cambiar cuando modifique una aplicación debería (no debe) ayudarme a cometer menos errores. Otra cosa que hay que notar es que soy el único desarrollador que trabaja en esto, ningún equipo en este momento, pero el enfoque de la base de datos múltiple debería ser un concepto más fácil de comprender para el desarrollador después de mí. –

Es posible que en el futuro también desee implementar N instancias de app1 (conmutación por error, o sirviendo a clientes internos/externos o lo que sea) y M instancias de app2 (la misma razón pero M! = N). Y si le preocupa la coherencia referencial de los datos, puede valer la pena ejecutar diariamente un script de reconciliación simple y enviar un informe a las personas a cargo en caso de problemas – bobah

THAT no suena como "un montón de aplicaciones" en absoluto, sino como "una aplicación sistema de ación con diferentes ejecutables ". Naturalmente, pueden compartir una base de datos. Haga un uso inteligente de Schemata para aislar las diferentes áreas funcionales dentro de una base de datos.

Fuente

2010-05-10 17:50:17 TomTom

Son muchas aplicaciones, solo comparten la misma base de usuarios y una necesidad de tener claves foráneas para las tablas "UserProfiles", pero su funcionalidad es totalmente diferente. –

Separe las bases de datos entonces, y un subsistema de membresía separado;) – TomTom

En nuestro negocio, fuimos con una base de datos separada por aplicación, con referencias de bases de datos cruzadas para la pequeña cantidad de información compartida y un servidor vinculado ocasional. Esto ha funcionado bastante bien con entornos de desarrollo, puesta en escena, construcción y producción.

Para los usuarios, toda nuestra base de usuarios se encuentra en las ventanas. Usamos Active Directory para administrar a los usuarios con referencias de aplicaciones a grupos, para que las aplicaciones no tengan que administrar usuarios, lo que es bueno. No centralizamos la gestión del grupo, es decir, cada aplicación tiene tablas para grupos y seguridad que no es tan agradable pero funciona.

Recomendaría, si sus aplicaciones son realmente diferentes, tener una base de datos por aplicación. Mirando hacia atrás, la base de datos compartida central para los usuarios también funciona.

Puede utilizar disparadores para la integridad referencial entre bases de datos:

Crear un servidor vinculado al servidor que contiene la base de datos que desea hacer referencia. Luego use el nombre de 4 partes para hacer referencia a la tabla en la base de datos remota que contiene los datos de referencia. Luego coloque esto en la inserción y actualice los disparadores en la tabla.

Ejemplo (asume inserciones de fila individuales y actualizaciones):

DECLARE @ref (datatype appropriate to your field) 

SELECT @ref = refField FROM inserted 

IF NOT EXISTS (SELECT * 
FROM referenceserver.refDB.dbo.refTable 
WHERE refField = @ref) 
BEGIN 
RAISERROR(...) 
ROLLBACK TRAN 
END

Para hacer inserciones de fila múltiples y actualizaciones que pueden unirse a las tablas en el campo de referencia pero puede ser muy lento.

Fuente

2010-05-10 23:32:30 Decker97

Me encantaría usar Active Directory, de esa manera no tendría ninguno de los problemas que menciono aquí, pero estamos usando otras formas de autenticar personas. Podría ir con referencias cruzadas de bases de datos y servidores vinculados, pero de esa manera perdería integridad referencial (al menos en el servidor sql, no sé si eso pasaría en otro RDBMS), que me gustaría conservar. Esta es la primera vez que me enfrento a este problema, así que estoy perdido aquí. Ninguna de las soluciones parece correcta. –

Creo que la respuesta a esta pregunta depende completamente de sus requisitos no funcionales. Si está diseñando una aplicación que algún día tendrá que implementarse en cientos de nodos, entonces necesita diseñar su base de datos para que, de ser necesario, pueda escalarse horizontalmente. Si, por otro lado, esta aplicación debe ser utilizada por una mano llena de usuarios y puede tener una vida útil corta, entonces su enfoque será diferente. Hace poco escuché un podcast sobre cómo se configuró la arquitectura de EBAY, http://www.se-radio.net/podcast/2008-09/episode-109-ebay039s-architecture-principles-randy-shoup, y tienen una base de datos por flujo de aplicaciones y usan fragmentación para dividir tablas en nodos físicos. Ahora sus requisitos no funcionales son que el sistema está disponible 24/7, es rápido, puede admitir miles de usuarios y no pierde datos importantes. EBAY gana millones de libras y, por lo tanto, puede respaldar el esfuerzo que esto requiere desarrollar y mantener.

De todos modos, esto no responde a su pregunta :) mi opinión personal sería asegurarse de que sus requisitos no funcionales hayan sido documentados y firmados por alguien. De esta forma puedes decidir sobre la mejor Arquitectura. Me sentiría tentado de tener cada aplicación usando su propia base de datos y una base de datos central para compartir datos. Y trataría de minimizar las dependencias entre ellos, lo cual estoy seguro no es fácil o lo hubieras hecho :), pero también intentaría evitar tener que producir algún tipo de software de middle ware para mantener las tablas en sincronización, ya que esto podría crear un dolor de cabeza para usted.

Al final del día, necesitas poner tu sistema en funcionamiento y los chicos con el pelo puntiagudo no darán un chuff de monos sobre lo genial que es tu diseño.

Fuente

2010-05-12 07:34:02 itworkedonmachine

Gracias por el enlace de podcast, lo escucharé tan pronto como tenga la oportunidad. Sé que los chicos de pelo puntiagudo no se darán cuenta de mi diseño, pero yo y otros desarrolladores lo harán, y cuanto menos doloroso lo pueda hacer para mí, mejor para los desarrolladores después de mí. –

Fuimos para dividir la base de datos y tener una base de datos común para todas las tablas compartidas. Debido a que todos estaban en la instancia de guardar SQL Server, no afectó el costo de ejecutar consultas en múltiples bases de datos.

La clave en la replicación para nosotros era que todo el servidor estaba en una máquina virtual (VM), por lo que para la replicación crear entornos Dev/Test, IT Support simplemente creaba una copia de esa imagen y restauraba copias adicionales cuando era necesario.

Fuente

2010-05-12 07:44:39 kevchadders

Base de datos por aplicación VS Una gran base de datos para todas las aplicaciones

Respuesta

Cuestiones relacionadas