Migración de Base de Datos

Hola,

yo no separaría las tablas en distintas bases de datos:
-No podrás definir claves ajenas (podrías implementarla mediante triggers);
-no podrás crear vistas indexadas,
-no podrás crear udf's with schemabinding.
-deberás gestionar usuarios por cada base de datos.
-Si bien es cierto que la copia de seguridad la podrás realizar por cada base de datos, en SQL Server 2000 puedes realizar copias de seguridad de ficheros que te resolvería el mismo problema.

¿qué quieres decir con simplificar la seguridad? Gracias

Saludos,

Eladio Rincón
SQL Server MVP
http://eladio.europe.webmatrixhosting.net



"Comparte lo que sabes, aprende lo que no sepas." FGG

"María Sánchez" escribió en el mensaje news:05a001c39353$c2be0eb0$
Estamos planificando un proyecto de Migración de Bases de
Datos de MS-SqlServer 6.5 a MS-SqlServer 2000.

Actualmente tenemos muchas tablas(con la información de
todas las areas de la empresa: Ventas, Compras,
Contabilidad, Finanzas, Producción, etc.) en una sola Base
de Datos y estamos evaluando la posibilidad de contemplar
en el proyecto la separación de las tablas en varias Bases
de Datos (BD de Ventas, BD de Producción, etc.)con esto
podriamos simplificar la seguridad y reducir el impacto en
la operatividad de la Empresa en caso de tener problemas
con una de las Bases de Datos.

En base a su experiencia, qué sugerencias pueden dar al
respecto? Se pueden esperar mejoras en los tiempos de
Respuestas de Sql o más bien empeoran? Qué precauciones se
deben tener?

Eladio gracias por tu valiosa respuesta.

Cuando hablo de simplificar, me refiero a que por ejemplo
a un Vendedor le pudiera dar acceso de Consulta,Creación y
Modificación a todas las tablas de la BD de Ventas y solo
derecho de consulta a las tablas de la BD de Producción.

Actualmente asignamos los derechos por Grupos, pero
tenemos que ir tabla por tabla dando derechos según el
área operativa a la que pertenezca la tabla.

Mostrar la cita

Hola,

yo no separaría las tablas en distintas bases de datos:
-No podrás definir claves ajenas (podrías implementarla

mediante triggers);
Mostrar la cita

-no podrás crear vistas indexadas,
-no podrás crear udf's with schemabinding.
-deberás gestionar usuarios por cada base de datos.
-Si bien es cierto que la copia de seguridad la podrás

realizar por cada base de datos, en SQL Server 2000 puedes
realizar copias de seguridad de ficheros que te resolvería
el mismo problema.
Mostrar la cita

¿qué quieres decir con simplificar la seguridad? Gracias

Saludos,

Eladio Rincón
SQL Server MVP
http://eladio.europe.webmatrixhosting.net



"Comparte lo que sabes, aprende lo que no sepas." FGG

"María Sánchez"

escribió en el mensaje news:05a001c39353$c2be0eb0
$
Mostrar la cita

Estamos planificando un proyecto de Migración de Bases de
Datos de MS-SqlServer 6.5 a MS-SqlServer 2000.

Actualmente tenemos muchas tablas(con la información de
todas las areas de la empresa: Ventas, Compras,
Contabilidad, Finanzas, Producción, etc.) en una sola

Base
Mostrar la cita

de Datos y estamos evaluando la posibilidad de contemplar
en el proyecto la separación de las tablas en varias

Bases
Mostrar la cita

de Datos (BD de Ventas, BD de Producción, etc.)con esto
podriamos simplificar la seguridad y reducir el impacto

en
Mostrar la cita

la operatividad de la Empresa en caso de tener problemas
con una de las Bases de Datos.

En base a su experiencia, qué sugerencias pueden dar al
respecto? Se pueden esperar mejoras en los tiempos de
Respuestas de Sql o más bien empeoran? Qué precauciones

se
Mostrar la cita

deben tener?

.

Hola Maria:
A pesar que me parece que efectivamente podrias a lograr una
simplificacion en la seguridad, el "precio" que debes pagar me parece
demasiado alto, sobre todo por perder la Integridad Referencial (Llaves
Foraneas) y los beneficios me parecen minimos.
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.
María Sánchez escribio:
Mostrar la cita

Eladio gracias por tu valiosa respuesta.

Cuando hablo de simplificar, me refiero a que por ejemplo
a un Vendedor le pudiera dar acceso de Consulta,Creación y
Modificación a todas las tablas de la BD de Ventas y solo
derecho de consulta a las tablas de la BD de Producción.

Actualmente asignamos los derechos por Grupos, pero
tenemos que ir tabla por tabla dando derechos según el
área operativa a la que pertenezca la tabla.

Mostrar la cita

Hola,

yo no separaría las tablas en distintas bases de datos:
-No podrás definir claves ajenas (podrías implementarla mediante
triggers);
-no podrás crear vistas indexadas,
-no podrás crear udf's with schemabinding.
-deberás gestionar usuarios por cada base de datos.
-Si bien es cierto que la copia de seguridad la podrás

realizar por cada base de datos, en SQL Server 2000 puedes
realizar copias de seguridad de ficheros que te resolvería
el mismo problema.
Mostrar la cita

¿qué quieres decir con simplificar la seguridad? Gracias

Saludos,

Eladio Rincón
SQL Server MVP
http://eladio.europe.webmatrixhosting.net



"Comparte lo que sabes, aprende lo que no sepas." FGG

"María Sánchez"

escribió en el mensaje news:05a001c39353$c2be0eb0
$
Mostrar la cita

Estamos planificando un proyecto de Migración de Bases de
Datos de MS-SqlServer 6.5 a MS-SqlServer 2000.

Actualmente tenemos muchas tablas(con la información de
todas las areas de la empresa: Ventas, Compras,
Contabilidad, Finanzas, Producción, etc.) en una sola Base
de Datos y estamos evaluando la posibilidad de contemplar
en el proyecto la separación de las tablas en varias Bases
de Datos (BD de Ventas, BD de Producción, etc.)con esto
podriamos simplificar la seguridad y reducir el impacto en
la operatividad de la Empresa en caso de tener problemas
con una de las Bases de Datos.

En base a su experiencia, qué sugerencias pueden dar al
respecto? Se pueden esperar mejoras en los tiempos de
Respuestas de Sql o más bien empeoran? Qué precauciones se
deben tener?

.