Tener actualizados los SPs? ¿que método?

Pues simplemente tener actualizados los SP, Vistas, Triggers y demás en
bases de datos similares


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

hola Pablete !! :)

Yo opino que debes ir por la opción 3 por la siguiente razón; imaginate que
generas otra versión de tu aplicativo (cosa que no sucede con mucha
frecuencia :))... ¿qué tendrás que hacer? tendrás que generar tu paquete de
distribución para las bases de datos que ya tengas, además de en caso de
elegir la opción 1 distribuirlo en master también.


Sobre herramientas, pues puedes hacerlo desde Visual Studio Team System for
DBPros, hasta generar script desde SSMS, hasta hacerte una aplicación ad-hoc
utilizando SMO... me temo que al final, ninguna (o pocas) aplicaciones
comerciales te van a ofrecer lo que necesites, y tendrás que tirar por hacer
algo personalizado.


Tengo una pregunta: ¿por qué quieres separar la información en distintas
bases de datos? Son clientes distintos, o así... lo digo porque SQL Server
necesitará (Memoria X Bases De Datos) para simplemente gestionar caché de
procesos, caché de datos, caché de conexiones, etc...


Quizás puede parecer una tontería, pero hace bien poco, estuvimos haciendo
un estudio de escalabidad para un cliente, y los principales limitante en la
escalabilidad del sistema fueron:
1) La aplicación .NET
2) El número de empresas a gestionar (1 empresa = 1 base de datos).




Saludos,

Eladio Rincón,
SQL Server MVP
http://blogs.solidq.com/es/elrincondeldba

"Pablo Roca" wrote in message
news:

Leyendo un comentario de Miguel Egea sobre como tener los SPs al dia en
las bases de datos.

Me surge la duda de como hacerlo,

1.- Los creas en la BBDD model, cuando ejecutes create database ya estarán
(los sps y todas las tablas que tengas).

2.- llamandolos con sp_ y poniendolos en master, además de marcarlos como
objetos del sistema. Se ejecutan en el entorno de la BBDD en que estés,
pero
solo los tienes una vez, lo que hace más fácil su administracio´n.

3, con una herramienta que los sincronice a partir de una base de datos
modelo que tendria en blanco. ¿Alguna recomendada?

¿Cual es vuestra opinión? Yo estoy casi por irme a la tercera opción.


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

Hola! :)))

Ya ves .. aquí empezando a dar guerra. :))

Si, yo tambien estoy casi que por la opción 3.

SMSS está bien, pero es un poco a mano, te dá solo los CREATEs y tu te lo
montas. Para SMO por lo que veo me lo tendría que currar yo, y en estos
momentos como que no ando con mucho tiempo .. uff .. y el VSTS pues no lo
ví.

Yo buscaba algo mas automático, sin tener de momento que meter mucho la mano
en él. Aquñi a mano tengo el XCASE 8, que parece que hace parte de lo que
quiero .. pero no lo hace todo :(((

Voy a mirar el Apex Diff y el Red Gate SQL Compare, gracias.


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

Ah .. se me olvidó la segunda parte.

Tengo una pregunta: ¿por qué quieres separar la información en distintas
bases de datos? Son clientes distintos, o así... lo digo porque SQL Server
necesitará (Memoria X Bases De Datos) para simplemente gestionar caché de
procesos, caché de datos, caché de conexiones, etc...


Quizás puede parecer una tontería, pero hace bien poco, estuvimos haciendo
un estudio de escalabidad para un cliente, y los principales limitante en
la escalabilidad del sistema fueron:
1) La aplicación .NET

Jodidos developers .. jajaja, que cruz tenemos! :)))

2) El número de empresas a gestionar (1 empresa = 1 base de datos).

Bueno, es para una aplicación en mi empresa .. y necesito distintas bases de
datos, porque guardan conjuntos de información distinta. Te explico:

Tenemos sobre unas 30 empresas, con distintos CIF, articulos diferentes,
clientes distintos (en algun caso raro entre algunas empresas si que pueden
ser iguales)

Casi (no del todo) descartando ya el modelo de una base de datos para cada
empresa-ejercicio, lo planteo de la siguiente manera:

Una base de datos por empresa (para los 5 ultimos ejercicios en vigor)
Una base de datos por empresa (para todos los ejercicios mas antiguos de 5
años).

Voy en 60 bases de datos, podria ingeniarme algun sistema para que solo
fueran 31 (las 30 empresas mas todas las empresas archivadas en una sola
base de datos, cosa que me daría problemas de programación añadidos).

¿Porque aun me resisto a descartar una base de datos por cada
empresa-ejercicio?

Si junto, digamos que 5 años en una base de datos, pues en ciertas empresas
tendré un volumen de datos que no voy a utilizar habitualmente, normalmente
estoy usando la información del ultimo año (hay tablas que tengo con casi 3
millones de registros por ejercicio) y el juntarlos solo por hacer un
analisis posterior, puede tener mas problemas que ventajas. Un analisis
multianual se suele hacer con poca frecuencia, vamos a decir que como mucho
una vez cada quince dias, pero lo que son consultas a los movimientos de un
año, pues de esas tengo infinidad de ellas.


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

Quizás puede parecer una tontería, pero hace bien poco, estuvimos
haciendo un estudio de escalabidad para un cliente, y los principales
limitante en la escalabilidad del sistema fueron:
1) La aplicación .NET

Jodidos developers .. jajaja, que cruz tenemos! :)))

Ni mucho menos, la aplicación está muy bien hecha, y bien estructurada, pero
uno de sus handicaps era que tiran de TS a través de blades, por lo que a
poco que se le aprieta, pues se nota

2) El número de empresas a gestionar (1 empresa = 1 base de datos).

Bueno, es para una aplicación en mi empresa .. y necesito distintas bases
de datos, porque guardan conjuntos de información distinta. Te explico:

Tenemos sobre unas 30 empresas, con distintos CIF, articulos diferentes,
clientes distintos (en algun caso raro entre algunas empresas si que
pueden ser iguales)

Casi (no del todo) descartando ya el modelo de una base de datos para cada
empresa-ejercicio, lo planteo de la siguiente manera:

Una base de datos por empresa (para los 5 ultimos ejercicios en vigor)
Una base de datos por empresa (para todos los ejercicios mas antiguos de 5
años).

Voy en 60 bases de datos, podria ingeniarme algun sistema para que solo
fueran 31 (las 30 empresas mas todas las empresas archivadas en una sola
base de datos, cosa que me daría problemas de programación añadidos).

¿Porque aun me resisto a descartar una base de datos por cada
empresa-ejercicio?

Si junto, digamos que 5 años en una base de datos, pues en ciertas
empresas tendré un volumen de datos que no voy a utilizar habitualmente,
normalmente estoy usando la información del ultimo año (hay tablas que
tengo con casi 3 millones de registros por ejercicio) y el juntarlos solo
por hacer un analisis posterior, puede tener mas problemas que ventajas.
Un analisis multianual se suele hacer con poca frecuencia, vamos a decir
que como mucho una vez cada quince dias, pero lo que son consultas a los
movimientos de un año, pues de esas tengo infinidad de ellas.


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

Por lo que leo, las bases de datos son muy independientes unas de otras, por
lo que tu aproximación de bases de datos por empresa, la veo correcta. Una
cosa que no me has dejado claro, es si va a haber consultas
inter-empresas... supongo qeu on será frecuente. Y por ultimo, y creo que lo
deja listo es el tema de integridad referencial: que sepas que no se puede
montar entre bases de datos, a menos que te lo montes mediante triggers...



¿me has hablado de 3 millones de filas por ejercicio? recuerda que el tamaño
solo importará (no se si estoy generalizando demasiado) para operaciones de
mantenimiento como reindexación, y reorganización de índices. Al final, las
cosas son muy simples, indexa para optimizar tus consultas,


Por cierto, en SQL Server 2007, si he leido bien que todavía no lo he
probado, vas a poder reindexar parciamente las tablas; me estoy imaginando
algo así como decir, voy a reindexar la tabla Apuntes, pero sólo los apuntes
que corresponden a tal periodo... algo así como llevar a la enesima
expresión el particionado de datos :)




Saludos,

Eladio Rincón,
SQL Server MVP
http://blogs.solidq.com/es/elrincondeldba