Diseño de base de datos

14/11/2003 - 15:03 por Fabian Lopez | Informe spam
Necesito realizar el diseño de una base de datos la cual
debera contener por lo menos 160 campos de datos. La
mayor parte de estos campos es textual por lo que la
longitud de registro es grande, al realizar algunas
pruebas de escritorio encontre que la velocidad de SQL
Server se ve afectada por esta cantidad de campo, lei un
articulo en interner que sugerian la particion horizontal
como solucion la cual consiste en dividir la informacion
en dos tablas distintas, una con la informacion mas
utilizada y otra con la menos utilizada, pero apesar de
ello la velocidad no es muy buena, que mas me pueden
sugerir como solucion para este problema. Ademas de ello
otra pregunta cuando utilizo una base de datos para
almacenar archivos el resultado no es muy bueno puesto
que la base de datos tiene un peso mayor a la suma total
de los archivos.

Preguntas similare

Leer las respuestas

#1 Accotto Maximiliano D.
14/11/2003 - 15:33 | Informe spam
Hola!! mira no se q queres hacer pero 160 textuales?? q tipo de datos estas
usando?.

Si a tu BDD le pones los Archivos dentro, se pondra lento lento la cosa!!
pero bueno esta de poner los archivos dentro de la BDD es una discusion de
decadas diria!! jeej (no hay recetas magicas).

Porque no me explicas un poco mas esa tabla de 160 campos como esta
conformada en su mayoria,Si tiene indices etc.

Seria muy bueno ademas q indiques por ej cantidad de registros,version de
sql,service pack,so,y algo del fierro digamos.

Ahh y porque dices q es lento? contra q lo comparas o como estas haciendo
esas pruebas.

Creo q con estas cosas te puedo orientar mas, sino te voy a empezar a dar
algunos consejos practicos q quizas no sean aplicables para ti.

Un saludo

Accotto Maximiliano Damian
Fundicion San Cayetano S.A
4002 - 4010
Gerente de Sistemas

"Fabian Lopez" escribió en el mensaje
news:0c4f01c3aab8$235f5320$
Necesito realizar el diseño de una base de datos la cual
debera contener por lo menos 160 campos de datos. La
mayor parte de estos campos es textual por lo que la
longitud de registro es grande, al realizar algunas
pruebas de escritorio encontre que la velocidad de SQL
Server se ve afectada por esta cantidad de campo, lei un
articulo en interner que sugerian la particion horizontal
como solucion la cual consiste en dividir la informacion
en dos tablas distintas, una con la informacion mas
utilizada y otra con la menos utilizada, pero apesar de
ello la velocidad no es muy buena, que mas me pueden
sugerir como solucion para este problema. Ademas de ello
otra pregunta cuando utilizo una base de datos para
almacenar archivos el resultado no es muy bueno puesto
que la base de datos tiene un peso mayor a la suma total
de los archivos.
Respuesta Responder a este mensaje
#2 Anonimo
14/11/2003 - 15:51 | Informe spam
Pues mira no todos son textuales pero son campos de
documentos de impuestos, con campos direcciones y
descripciones, la cantidad de registros diarios esta
calculado en dias de alto volumen en 40.000 registros y
por lo menos 10.000 registros en dias bajos, deberan
permancer dos años en la base de datos antes de poder ser
evacuados de la base de datos, incialmente tendra 15
usuarios aproximadamente pero hacia mitad de el siguiente
año tendra unos 60 ,SQL Server 2000 con Service Pack 3
Windows 2000 server, XEON 2.66 Ghz DD SCSI 34 GB. Se
plantea adicionarle RAID 5, pero pues depende de el
crecimiento de el proyecto. Mi razon para decir que lento
es que en las pruebas para realizar una consulta se
demora 5 sec con apenas 700.000 registros. Tiene un unico
indice que es el sticker de el documento, el cual es
ademas la llave pricipal


Gracias por tu colaboracion.

Fabian

Hola!! mira no se q queres hacer pero 160 textuales?? q


tipo de datos estas
usando?.

Si a tu BDD le pones los Archivos dentro, se pondra


lento lento la cosa!!
pero bueno esta de poner los archivos dentro de la BDD


es una discusion de
decadas diria!! jeej (no hay recetas magicas).

Porque no me explicas un poco mas esa tabla de 160


campos como esta
conformada en su mayoria,Si tiene indices etc.

Seria muy bueno ademas q indiques por ej cantidad de


registros,version de
sql,service pack,so,y algo del fierro digamos.

Ahh y porque dices q es lento? contra q lo comparas o


como estas haciendo
esas pruebas.

Creo q con estas cosas te puedo orientar mas, sino te


voy a empezar a dar
algunos consejos practicos q quizas no sean aplicables


para ti.

Un saludo

Accotto Maximiliano Damian
Fundicion San Cayetano S.A
4002 - 4010
Gerente de Sistemas

"Fabian Lopez"


escribió en el mensaje
news:0c4f01c3aab8$235f5320$
Necesito realizar el diseño de una base de datos la cual
debera contener por lo menos 160 campos de datos. La
mayor parte de estos campos es textual por lo que la
longitud de registro es grande, al realizar algunas
pruebas de escritorio encontre que la velocidad de SQL
Server se ve afectada por esta cantidad de campo, lei un
articulo en interner que sugerian la particion horizontal
como solucion la cual consiste en dividir la informacion
en dos tablas distintas, una con la informacion mas
utilizada y otra con la menos utilizada, pero apesar de
ello la velocidad no es muy buena, que mas me pueden
sugerir como solucion para este problema. Ademas de ello
otra pregunta cuando utilizo una base de datos para
almacenar archivos el resultado no es muy bueno puesto
que la base de datos tiene un peso mayor a la suma total
de los archivos.


.

Respuesta Responder a este mensaje
#3 dbuendiab
14/11/2003 - 22:09 | Informe spam
wrote in message news:<0ce401c3aabe$bacd9810$...
Pues mira no todos son textuales pero son campos de
documentos de impuestos, con campos direcciones y
descripciones, la cantidad de registros diarios esta
calculado en dias de alto volumen en 40.000 registros y
por lo menos 10.000 registros en dias bajos, deberan
permancer dos a os en la base de datos antes de poder ser
evacuados de la base de datos, incialmente tendra 15
usuarios aproximadamente pero hacia mitad de el siguiente
a o tendra unos 60 ,SQL Server 2000 con Service Pack 3
Windows 2000 server, XEON 2.66 Ghz DD SCSI 34 GB. Se
plantea adicionarle RAID 5, pero pues depende de el
crecimiento de el proyecto. Mi razon para decir que lento
es que en las pruebas para realizar una consulta se
demora 5 sec con apenas 700.000 registros. Tiene un unico
indice que es el sticker de el documento, el cual es
ademas la llave pricipal



Yo te recomendaría que repartieses los 160 campos en varias tablas más
pequeñas que compartan clave principal, si fuera posible en torno a
los 2K? 8K? no recuerdo ahora el tamaño de página del SQL Server, pero
piensa que cuanto más ancho sea el registro menos ágil es el manejo de
páginas de SQL Server.

Diego Buendia
Barcelona Spain
email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaRespuesta Tengo una respuesta
Search Busqueda sugerida