Tener actualizados los SPs? ¿que método?

On Tue, 23 Oct 2007 16:33:28 +0200, "Pablo Roca"
wrote:

Con la 1 hay el problema que los cambios en dichos objetos no se repropagan
automaticamente en las bases de datos creadas a partir de dicho modelo. Solo
vale para la creación de las bases de datos (o por lo menos no ví como
hacerlo).

Los cambios tienes que guardarlos en un script a parte.

Cambias siempre la base de datos usando SQL y guardas las
instrucciones.

Por ejemplo tienes un script que te crea una base de datos de la
versión 1, y otro script que te convierte una base de datos de la
versión 1 en una de la versión 2.

Para actualizar de una versión a otra solo tienes que pasar la
secuencia de scripts correspondiente.

Si guardas la versión actual en la base de datos es muy fácil de
automatizar el proceso.

Si encuentras una herramienta que te genere esos scripts de
actualización automáticamente pues muy bien, pero tampoco es que haga
mucha falta si se tiene un poco de cuidado.


Saludos

Hola, ahh ok, puedes hacer varias cosas, lo mejor seria usar Visual Studio
for Database Profesional, pero hay buenas herramientas de terceros para
hacer comparaciones


-
Microsoft M.V.P en SQLServer
SQLTotal Consulting - Servicios en SQLServer
Email:
"Pablo Roca" escribió en el mensaje
news:eAF%23%

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

Gracias por la aclaración Alfredo.


Saludos,

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

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

eh? .. mande? .. jajajaja

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.

Si que lo son, fijate que el alguna empresa tenemos productos nuevos cada
año. El fletán de una marea de un barco, es distinto producto que el de otra
marea-barco (por darte un ejemplo).

Y aun no tengo descartado del todo lo de una base de datos por
empresa-ejercicio (cabezón que es uno :)))

Una cosa que no me has dejado claro, es si va a haber consultas
inter-empresas... supongo qeu on será frecuente.

Para nada. Eso en principio nunca lo habrá. Y si se necesita pues se
programa a pedal (nunca hizo falta).

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...

Ya, eso lei .. aun no ví como van los triggers en SQL Server. Pero
transacciones entre base de datos si .. no?

¿me has hablado de 3 millones de filas por ejercicio?

Si, en una de las tablas si. Y todo funcionando ok con Visual FoxPro :))))

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,

Y si la gente se quiere llevar los datos en un portatil? Ahi si que importa
el tamaño.

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 :)

Interesante, gracias, habrá que mirarlo.


Saludos,

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

Gracias Maxi


Saludos,

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