Referencias "remotas"

Hola:
Con muy pocas exepciones, la mejor opcion en fusionar A,B y C en una
sola Base de Datos y agregrar alguna columna a las Tablas que pertenecian a
A y B para distinguir los datos de una y de otra. La division en diferentes
bases de datos con frecuencia termina en muchos problemas. Cual es la razon
por la que esta asi dividida?
La alternativa de mantener la integridad referencial por triggers es
dificil de construir, lenta y dificil de dar mantenimiento. Pero es la unica
opcion cuando tienes este tipo de diseno.
Saludos,

Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

"Xavi" wrote in message
news:#

Hola a todos

Tengo 2 bases de datos en un mismo servidor ( llamémoslas A y B ) que
comparten datos en una tercera base de datos común a las dos anteriores (
llamémosla C ). La estructura de A y B es idéntica. En C hay una tabla a

la

cual se accede desde A y B a través de una vista en la propia base de

datos

que simplemente hace un SELECT de la tabla de C.

Me gustaría establecer una "integridad referencial" con esta tabla pero,
claro, están en bases de datos diferentes. Podría montar una historia con
triggers de comprobación de existencia a la hora de insertar, updatar y
eliminar, pero no sé si es la mejor opción.

¿Hay alguna idea al respecto?

Gracias


Xavi

Gracias por contestar.

El porqué de esta división también me lo pregunto yo porque tampoco lo
comparto. Resulta que viene dado ya de diseño, supongo que para tener
divididos los datos entre departamentos ... no sé muy bien la razón. Supongo
que también asusta el hecho de tener muchos registros en una misma tabla. Y
eso que ya uso una vista particionada por fecha. ¿Tal vez se deba
particionar también por departamento en una única base de datos?

El caso es que desconozco argumentos para forzar a fusionar todas las bases
de datos a una sola. La integridad referencial, el rendimiento, el número de
conexiones ( algunas utilizan MSDE ) parecen ser insignificantes
comparandolo con la posibilidad de tener dividido el gran volumen de datos.


Xavi


"Javier Loria" escribió en el mensaje
news:

Hola:
Con muy pocas exepciones, la mejor opcion en fusionar A,B y C en una
sola Base de Datos y agregrar alguna columna a las Tablas que pertenecian

a

A y B para distinguir los datos de una y de otra. La division en

diferentes

bases de datos con frecuencia termina en muchos problemas. Cual es la

razon

por la que esta asi dividida?
La alternativa de mantener la integridad referencial por triggers es
dificil de construir, lenta y dificil de dar mantenimiento. Pero es la

unica

opcion cuando tienes este tipo de diseno.
Saludos,

Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

"Xavi" wrote in message
news:#
> Hola a todos
>
> Tengo 2 bases de datos en un mismo servidor ( llamémoslas A y B ) que
> comparten datos en una tercera base de datos común a las dos anteriores

(

> llamémosla C ). La estructura de A y B es idéntica. En C hay una tabla a
la
> cual se accede desde A y B a través de una vista en la propia base de
datos
> que simplemente hace un SELECT de la tabla de C.
>
> Me gustaría establecer una "integridad referencial" con esta tabla pero,
> claro, están en bases de datos diferentes. Podría montar una historia

con

> triggers de comprobación de existencia a la hora de insertar, updatar y
> eliminar, pero no sé si es la mejor opción.
>
> ¿Hay alguna idea al respecto?
>
> Gracias
>
>
> Xavi
>
>

Hola Xavi:
Buen punto.
En principio el concepto de Base de Datos esta asociado con la captura
de informacion de una Empresa. Al principio del mundo relacional no se
contemplo nunca la necesidad de multiples Bd, pero el alto costo de los
motores, exigio que se manejaran varias empresas en una solo servidor y
entonces fue cuando se popularizo esta posiblidad.
Mi experiencia es similar a la tuya con respecto al miedo de mantener
muchas filas en una sola tabla, pero es claro que SQL Server maneja con
facilidad Tablas de centenas de millones de filas, conozco de algunos
servidores (1 procesador y muchos discos), con tablas de 70/80 millones de
filas, y varios Gigas de espacio en disco en una Tabla.
Cuando se produce particionamiento horizontal, normalmente es mejor no
hacerlo por Fecha ya que se produce congestion en un solo punto, lo mejor es
buscar otro criterio para particionar, geograficamente el mas popular. Aun
cuando particionas fisicamente tiene sentido esconder el particionamento por
medio de vistas.
Por ultimo otra "pesadilla" del partir una empresa en multiples BD es el
respaldo, ya que es "imposible" en SQL hacer un respaldo en caliente
coordinado de las BD, tienes que hacer respaldos completos y del Log y hacer
recuperacion con la opcion de Point in Time para poner todo de forma que no
se rompa la integridad.

Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda



"Xavi" wrote in message
news:

Gracias por contestar.

El porqué de esta división también me lo pregunto yo porque tampoco lo
comparto. Resulta que viene dado ya de diseño, supongo que para tener
divididos los datos entre departamentos ... no sé muy bien la razón.

Supongo

que también asusta el hecho de tener muchos registros en una misma tabla.

Y

eso que ya uso una vista particionada por fecha. ¿Tal vez se deba
particionar también por departamento en una única base de datos?

El caso es que desconozco argumentos para forzar a fusionar todas las

bases

de datos a una sola. La integridad referencial, el rendimiento, el número

de

conexiones ( algunas utilizan MSDE ) parecen ser insignificantes
comparandolo con la posibilidad de tener dividido el gran volumen de

datos.

Xavi


"Javier Loria" escribió en el mensaje
news:
> Hola:
> Con muy pocas exepciones, la mejor opcion en fusionar A,B y C en una
> sola Base de Datos y agregrar alguna columna a las Tablas que

pertenecian

a
> A y B para distinguir los datos de una y de otra. La division en
diferentes
> bases de datos con frecuencia termina en muchos problemas. Cual es la
razon
> por la que esta asi dividida?
> La alternativa de mantener la integridad referencial por triggers es
> dificil de construir, lenta y dificil de dar mantenimiento. Pero es la
unica
> opcion cuando tienes este tipo de diseno.
> Saludos,
>
> Javier Loria
> Costa Rica
> Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
> que pueda ser copiado y pegado al Query Analizer.
> La version de SQL y Service Pack tambien ayuda
>
> "Xavi" wrote in message
> news:#
> > Hola a todos
> >
> > Tengo 2 bases de datos en un mismo servidor ( llamémoslas A y B ) que
> > comparten datos en una tercera base de datos común a las dos

anteriores

(
> > llamémosla C ). La estructura de A y B es idéntica. En C hay una tabla

a

> la
> > cual se accede desde A y B a través de una vista en la propia base de
> datos
> > que simplemente hace un SELECT de la tabla de C.
> >
> > Me gustaría establecer una "integridad referencial" con esta tabla

pero,

> > claro, están en bases de datos diferentes. Podría montar una historia
con
> > triggers de comprobación de existencia a la hora de insertar, updatar

y

> > eliminar, pero no sé si es la mejor opción.
> >
> > ¿Hay alguna idea al respecto?
> >
> > Gracias
> >
> >
> > Xavi
> >
> >
>
>