bases de datos con archivos incluidos

hola a todos:

tengo un problema de diseño de una aplicacion / base de datos y quisiera
pediros consejo si esta forma es optima

simplificando la aplicacion, donde residen mis dudas:

la idea de la aplicacion es:

de una base de datos cojo la lista de items mas unos cuantos atributos,
los
cuales seran evaluados por diferentes personas y mas de una vez cada uno,
la
evaluacion se realiza segun unas determinadas caracteristicas (poniendoles
nota de 0 a 10) , asi mismo se podran adjuntar uno o posiblemente mas de
un
archivo a un item-evaluacion

la aplicacion es simple excepto que el tamaño sera muy grande, hablando de
20.000 items iniciales pudiendo llegar a 100.000, quizas mas, y con varias
evaluaciones cada uno
los items tiene identificador unico en la actual base de datos que
utilizare
como source

mi idea es pues:
- una tabla donde alamaceno (con key = identificador de item) los item mas
los atributos de este (una sola vez por item) (copia local de parte del
source pues tan solo me interesan alunos item para su posterior
evaluacion)
- otra tabla donde alamaceno (con key = item + numero evaluacion) las
distintas notas para cada caracteristica (siempre las misma para todos los
items) y el indice de archivo
- y una tercera tabla donde almaceno los archivos (tipo de datos: imagen)
junto su descripcion e indice, (con key = indice de archivo)

mis dudas son pues:
- como haria si a un determinado item se quieren introducir mas de un
archivo?

- convendria almazenar los archivos externamente y no en el sql ? (un ftp
o
similar) por que?

decir que la aplicacion sera desarrollada en web (no por mi) y los
archivos
pudieran tener un tamaño de pocos Kbs supuestamente (documentos de texto,
docs, pequeñas fotos, algun esquema o tabla en excell), aunque nadie me
asegura que no se "mal-use" con archivos de gran tamaño

gracias por vuestras consideraciones

Lee entre lineas...

> hola a todos:

Hola!!!!

> tengo un problema de diseño de una aplicacion / base de datos y quisiera
> pediros consejo si esta forma es optima
>
> simplificando la aplicacion, donde residen mis dudas:
>
> la idea de la aplicacion es:
>
> de una base de datos cojo la lista de items mas unos cuantos atributos,
> los
> cuales seran evaluados por diferentes personas y mas de una vez cada

> la
> evaluacion se realiza segun unas determinadas caracteristicas

> nota de 0 a 10) , asi mismo se podran adjuntar uno o posiblemente mas de
> un
> archivo a un item-evaluacion
>
> la aplicacion es simple excepto que el tamaño sera muy grande, hablando

> 20.000 items iniciales pudiendo llegar a 100.000, quizas mas, y con

> evaluaciones cada uno
> los items tiene identificador unico en la actual base de datos que
> utilizare
> como source

No veo un problema en ese numero de registros para SQLServer en una

mediamente potente y con suficiente memoria.

> mi idea es pues:
> - una tabla donde alamaceno (con key = identificador de item) los item

> los atributos de este (una sola vez por item) (copia local de parte del
> source pues tan solo me interesan alunos item para su posterior
> evaluacion)
> - otra tabla donde alamaceno (con key = item + numero evaluacion) las
> distintas notas para cada caracteristica (siempre las misma para todos

> items) y el indice de archivo
> - y una tercera tabla donde almaceno los archivos (tipo de datos:

> junto su descripcion e indice, (con key = indice de archivo)
>
> mis dudas son pues:
> - como haria si a un determinado item se quieren introducir mas de un
> archivo?

La clave seria tan simple como un autonumerico + item.

> - convendria almazenar los archivos externamente y no en el sql ? (un

> o
> similar) por que?
>

Seguro que hay mucha gente en contra, pero yo soy partidario de dejarlos
fuera en este caso. El mótivo es que te facilitara la vida a la hora de
visualizar los documentos en el navegador y manejarlos desde asp.net. El
principal problema, el tema de que las copias de seguridad de la base de
datos no son suficientes para proteger todos los datos que maneja la
aplicación.

> decir que la aplicacion sera desarrollada en web (no por mi) y los
> archivos
> pudieran tener un tamaño de pocos Kbs supuestamente (documentos de

> docs, pequeñas fotos, algun esquema o tabla en excell), aunque nadie me
> asegura que no se "mal-use" con archivos de gran tamaño

La aplicación asp.net puede controlar facilmente el tamaño maximo de los
archivos para evitar un uso abusivo. Tambien podria usar compresión a la
hora de almacenalos de manera transparente al usuario.

> gracias por vuestras consideraciones


Un saludo
Rodrigo Corral González [MVP]

FAQ de microsoft.public.es.vc++
http://rcorral.mvps.org

Gracias por contestar

mi principal preocupacion del numero de registros es por la existencia de
los archivos adjuntos, por ejemplo, si llegase a 50.000 items, y unas 10
evaluaciones, y los archivos una media de 100 kb, serian unos 50gb, no??,

que me parece excesivo para el SQL-server (supongo problemas de
relentizacion, de backups, etc...), corrigeme si no estoy en lo cierto

ademas los archivos son de apoyo, lo principal son las notas de cada
evaluacion


y una cosa mas, el tema del autonomerico mas indice de archivo

la cosa seria
Tabla principal -> insertar un numero para item/evaluacion (autonumerico)
Tabla archivos -> autonumerico (pseudo) mas indice de archivo (1 para el
primer, 2 para el segundo...)

asi pues a la hora de querer recuperar los archivos para un

dados, busco en la tabla de archivos el numero de archivos que satisfacen
ese autonumerico, y con el indice excojo si quiero el primero, segundo,
etc.., no ?




"Rodrigo Corral [MVP]" wrote in message
news:%
> Lee entre lineas...
>
> > hola a todos:
>
> Hola!!!!
>
> > tengo un problema de diseño de una aplicacion / base de datos y

> > pediros consejo si esta forma es optima
> >
> > simplificando la aplicacion, donde residen mis dudas:
> >
> > la idea de la aplicacion es:
> >
> > de una base de datos cojo la lista de items mas unos cuantos

> > los
> > cuales seran evaluados por diferentes personas y mas de una vez cada
uno,
> > la
> > evaluacion se realiza segun unas determinadas caracteristicas
(poniendoles
> > nota de 0 a 10) , asi mismo se podran adjuntar uno o posiblemente mas

> > un
> > archivo a un item-evaluacion
> >
> > la aplicacion es simple excepto que el tamaño sera muy grande,

de
> > 20.000 items iniciales pudiendo llegar a 100.000, quizas mas, y con
varias
> > evaluaciones cada uno
> > los items tiene identificador unico en la actual base de datos que
> > utilizare
> > como source
>
> No veo un problema en ese numero de registros para SQLServer en una
máquina
> mediamente potente y con suficiente memoria.
>
> > mi idea es pues:
> > - una tabla donde alamaceno (con key = identificador de item) los item
mas
> > los atributos de este (una sola vez por item) (copia local de parte

> > source pues tan solo me interesan alunos item para su posterior
> > evaluacion)
> > - otra tabla donde alamaceno (con key = item + numero evaluacion) las
> > distintas notas para cada caracteristica (siempre las misma para todos
los
> > items) y el indice de archivo
> > - y una tercera tabla donde almaceno los archivos (tipo de datos:
imagen)
> > junto su descripcion e indice, (con key = indice de archivo)
> >
> > mis dudas son pues:
> > - como haria si a un determinado item se quieren introducir mas de un
> > archivo?
>
> La clave seria tan simple como un autonumerico + item.
>
> > - convendria almazenar los archivos externamente y no en el sql ? (un
ftp
> > o
> > similar) por que?
> >
>
> Seguro que hay mucha gente en contra, pero yo soy partidario de dejarlos
> fuera en este caso. El mótivo es que te facilitara la vida a la hora de
> visualizar los documentos en el navegador y manejarlos desde asp.net. El
> principal problema, el tema de que las copias de seguridad de la base de
> datos no son suficientes para proteger todos los datos que maneja la
> aplicación.
>
> > decir que la aplicacion sera desarrollada en web (no por mi) y los
> > archivos
> > pudieran tener un tamaño de pocos Kbs supuestamente (documentos de
texto,
> > docs, pequeñas fotos, algun esquema o tabla en excell), aunque nadie

> > asegura que no se "mal-use" con archivos de gran tamaño
>
> La aplicación asp.net puede controlar facilmente el tamaño maximo de los
> archivos para evitar un uso abusivo. Tambien podria usar compresión a la
> hora de almacenalos de manera transparente al usuario.
>
> > gracias por vuestras consideraciones
>
>
> Un saludo
> Rodrigo Corral González [MVP]
>
> FAQ de microsoft.public.es.vc++
> http://rcorral.mvps.org
>
>

Por el volumen de datos no te preocupes, SQL Server maneja perfectamente
volumenes de datos muchísimo más elevador. :-)

Un saludo
Salvador Ramos
Murcia - España
[Microsoft MVP SQL Server]
www.helpdna.net
¿ Te interesa participar en las reuniones
del grupo de Usuarios de SQL Server y .NET ?
Se harán en levante de España, (Alicante o Murcia)?

"Mara" escribió en el mensaje
news:
> Gracias por contestar
>
> mi principal preocupacion del numero de registros es por la existencia

> los archivos adjuntos, por ejemplo, si llegase a 50.000 items, y unas 10
> evaluaciones, y los archivos una media de 100 kb, serian unos 50gb,

lo
> que me parece excesivo para el SQL-server (supongo problemas de
> relentizacion, de backups, etc...), corrigeme si no estoy en lo cierto
>
> ademas los archivos son de apoyo, lo principal son las notas de cada
> evaluacion
>
>
> y una cosa mas, el tema del autonomerico mas indice de archivo
>
> la cosa seria
> Tabla principal -> insertar un numero para item/evaluacion

> Tabla archivos -> autonumerico (pseudo) mas indice de archivo (1 para el
> primer, 2 para el segundo...)
>
> asi pues a la hora de querer recuperar los archivos para un
item/evaluacion
> dados, busco en la tabla de archivos el numero de archivos que

> ese autonumerico, y con el indice excojo si quiero el primero, segundo,
> etc.., no ?
>
>
>
>
> "Rodrigo Corral [MVP]" wrote in message
> news:%
> > Lee entre lineas...
> >
> > > hola a todos:
> >
> > Hola!!!!
> >
> > > tengo un problema de diseño de una aplicacion / base de datos y
quisiera
> > > pediros consejo si esta forma es optima
> > >
> > > simplificando la aplicacion, donde residen mis dudas:
> > >
> > > la idea de la aplicacion es:
> > >
> > > de una base de datos cojo la lista de items mas unos cuantos
atributos,
> > > los
> > > cuales seran evaluados por diferentes personas y mas de una vez cada
> uno,
> > > la
> > > evaluacion se realiza segun unas determinadas caracteristicas
> (poniendoles
> > > nota de 0 a 10) , asi mismo se podran adjuntar uno o posiblemente

de
> > > un
> > > archivo a un item-evaluacion
> > >
> > > la aplicacion es simple excepto que el tamaño sera muy grande,
hablando
> de
> > > 20.000 items iniciales pudiendo llegar a 100.000, quizas mas, y con
> varias
> > > evaluaciones cada uno
> > > los items tiene identificador unico en la actual base de datos que
> > > utilizare
> > > como source
> >
> > No veo un problema en ese numero de registros para SQLServer en una
> máquina
> > mediamente potente y con suficiente memoria.
> >
> > > mi idea es pues:
> > > - una tabla donde alamaceno (con key = identificador de item) los

> mas
> > > los atributos de este (una sola vez por item) (copia local de parte
del
> > > source pues tan solo me interesan alunos item para su posterior
> > > evaluacion)
> > > - otra tabla donde alamaceno (con key = item + numero evaluacion)

> > > distintas notas para cada caracteristica (siempre las misma para

> los
> > > items) y el indice de archivo
> > > - y una tercera tabla donde almaceno los archivos (tipo de datos:
> imagen)
> > > junto su descripcion e indice, (con key = indice de archivo)
> > >
> > > mis dudas son pues:
> > > - como haria si a un determinado item se quieren introducir mas de

> > > archivo?
> >
> > La clave seria tan simple como un autonumerico + item.
> >
> > > - convendria almazenar los archivos externamente y no en el sql ?

> ftp
> > > o
> > > similar) por que?
> > >
> >
> > Seguro que hay mucha gente en contra, pero yo soy partidario de

> > fuera en este caso. El mótivo es que te facilitara la vida a la hora

> > visualizar los documentos en el navegador y manejarlos desde asp.net.

> > principal problema, el tema de que las copias de seguridad de la base

> > datos no son suficientes para proteger todos los datos que maneja la
> > aplicación.
> >
> > > decir que la aplicacion sera desarrollada en web (no por mi) y los
> > > archivos
> > > pudieran tener un tamaño de pocos Kbs supuestamente (documentos de
> texto,
> > > docs, pequeñas fotos, algun esquema o tabla en excell), aunque nadie
me
> > > asegura que no se "mal-use" con archivos de gran tamaño
> >
> > La aplicación asp.net puede controlar facilmente el tamaño maximo de

> > archivos para evitar un uso abusivo. Tambien podria usar compresión a

> > hora de almacenalos de manera transparente al usuario.
> >
> > > gracias por vuestras consideraciones
> >
> >
> > Un saludo
> > Rodrigo Corral González [MVP]
> >
> > FAQ de microsoft.public.es.vc++
> > http://rcorral.mvps.org
> >
> >
>
>

no si mi principal preocupacion no es que un sql-server no sea capaz de
manejarlo, si no que ese mismo sql server lo utilizamos para otras cosas y
en caso de un tal alto volumen, supongo que influiria en otras ejecuciones
(otras bases de datos) asi como tb en el espacio en disco




"Salvador Ramos" wrote in message
news:O8$
> Por el volumen de datos no te preocupes, SQL Server maneja perfectamente
> volumenes de datos muchísimo más elevador. :-)
>
> Un saludo
> Salvador Ramos
> Murcia - España
> [Microsoft MVP SQL Server]
> www.helpdna.net
> ¿ Te interesa participar en las reuniones
> del grupo de Usuarios de SQL Server y .NET ?
> Se harán en levante de España, (Alicante o Murcia)?
>
> "Mara" escribió en el mensaje
> news:
> > Gracias por contestar
> >
> > mi principal preocupacion del numero de registros es por la existencia
de
> > los archivos adjuntos, por ejemplo, si llegase a 50.000 items, y unas

> > evaluaciones, y los archivos una media de 100 kb, serian unos 50gb,
no??,
> lo
> > que me parece excesivo para el SQL-server (supongo problemas de
> > relentizacion, de backups, etc...), corrigeme si no estoy en lo cierto
> >
> > ademas los archivos son de apoyo, lo principal son las notas de cada
> > evaluacion
> >
> >
> > y una cosa mas, el tema del autonomerico mas indice de archivo
> >
> > la cosa seria
> > Tabla principal -> insertar un numero para item/evaluacion
(autonumerico)
> > Tabla archivos -> autonumerico (pseudo) mas indice de archivo (1 para

> > primer, 2 para el segundo...)
> >
> > asi pues a la hora de querer recuperar los archivos para un
> item/evaluacion
> > dados, busco en la tabla de archivos el numero de archivos que
satisfacen
> > ese autonumerico, y con el indice excojo si quiero el primero,

> > etc.., no ?
> >
> >
> >
> >
> > "Rodrigo Corral [MVP]" wrote in message
> > news:%
> > > Lee entre lineas...
> > >
> > > > hola a todos:
> > >
> > > Hola!!!!
> > >
> > > > tengo un problema de diseño de una aplicacion / base de datos y
> quisiera
> > > > pediros consejo si esta forma es optima
> > > >
> > > > simplificando la aplicacion, donde residen mis dudas:
> > > >
> > > > la idea de la aplicacion es:
> > > >
> > > > de una base de datos cojo la lista de items mas unos cuantos
> atributos,
> > > > los
> > > > cuales seran evaluados por diferentes personas y mas de una vez

> > uno,
> > > > la
> > > > evaluacion se realiza segun unas determinadas caracteristicas
> > (poniendoles
> > > > nota de 0 a 10) , asi mismo se podran adjuntar uno o posiblemente
mas
> de
> > > > un
> > > > archivo a un item-evaluacion
> > > >
> > > > la aplicacion es simple excepto que el tamaño sera muy grande,
> hablando
> > de
> > > > 20.000 items iniciales pudiendo llegar a 100.000, quizas mas, y

> > varias
> > > > evaluaciones cada uno
> > > > los items tiene identificador unico en la actual base de datos que
> > > > utilizare
> > > > como source
> > >
> > > No veo un problema en ese numero de registros para SQLServer en una
> > máquina
> > > mediamente potente y con suficiente memoria.
> > >
> > > > mi idea es pues:
> > > > - una tabla donde alamaceno (con key = identificador de item) los
item
> > mas
> > > > los atributos de este (una sola vez por item) (copia local de

> del
> > > > source pues tan solo me interesan alunos item para su posterior
> > > > evaluacion)
> > > > - otra tabla donde alamaceno (con key = item + numero evaluacion)
las
> > > > distintas notas para cada caracteristica (siempre las misma para
todos
> > los
> > > > items) y el indice de archivo
> > > > - y una tercera tabla donde almaceno los archivos (tipo de datos:
> > imagen)
> > > > junto su descripcion e indice, (con key = indice de archivo)
> > > >
> > > > mis dudas son pues:
> > > > - como haria si a un determinado item se quieren introducir mas de
un
> > > > archivo?
> > >
> > > La clave seria tan simple como un autonumerico + item.
> > >
> > > > - convendria almazenar los archivos externamente y no en el sql ?
(un
> > ftp
> > > > o
> > > > similar) por que?
> > > >
> > >
> > > Seguro que hay mucha gente en contra, pero yo soy partidario de
dejarlos
> > > fuera en este caso. El mótivo es que te facilitara la vida a la hora
de
> > > visualizar los documentos en el navegador y manejarlos desde

El
> > > principal problema, el tema de que las copias de seguridad de la

de
> > > datos no son suficientes para proteger todos los datos que maneja la
> > > aplicación.
> > >
> > > > decir que la aplicacion sera desarrollada en web (no por mi) y los
> > > > archivos
> > > > pudieran tener un tamaño de pocos Kbs supuestamente (documentos de
> > texto,
> > > > docs, pequeñas fotos, algun esquema o tabla en excell), aunque

> me
> > > > asegura que no se "mal-use" con archivos de gran tamaño
> > >
> > > La aplicación asp.net puede controlar facilmente el tamaño maximo de
los
> > > archivos para evitar un uso abusivo. Tambien podria usar compresión

la
> > > hora de almacenalos de manera transparente al usuario.
> > >
> > > > gracias por vuestras consideraciones
> > >
> > >
> > > Un saludo
> > > Rodrigo Corral González [MVP]
> > >
> > > FAQ de microsoft.public.es.vc++
> > > http://rcorral.mvps.org
> > >
> > >
> >
> >
>
>