Consejo sobre Estructura y Relaciones uno a uno 1 a 1

Hola a todos:

Tengo una duda sobre la estructura de la Base de Datos de mi Sistema de
Calculo Bursatil. Os cuento:

Sobre estructura de datos, normalizacion, entidades y limites de Sql Server
creo saber bastante.

Al diseñar la estructura tengo tres entidades o tablas principales
clarisimas, con relacion uno a muchos, que son Mercados, Valores de esos
Mercados, y Cotizaciones de esos Valores. Hasta aqui bien, todo claro.

Ahora veamos el resto. Tengo Calculos de esas Cotizaciones en relacion uno a
uno (1 a 1), y en la siguiente fase tengo Análisis de esas Cotizaciones,
tambien en relacion uno a uno (1 a 1), y luego Proyecciones de esas
Cotizaciones, tambien en relacion uno a uno (1 a 1).

Por análisis de entidades, son tablas distintas, pero por análisis de
normalizacion, deberia estar en una sola tabla, ya que se relacionan uno a
uno (1 a 1).

El volumen de datos no es grande, porque casi todos los campos son money y
tengo unos 50 o 60 campos en Calculos, 10 o 15 en Analisis y casi 300 en
Proyecciones. Lejos del limite de 1024 campos por tabla, que segun creo
permite Sql Server, y creo que tambien lejos de los 8 k'as por fila.

Pero eso si, esoy hablando de millones y millones de registros, voy por 25
millones y puedo llegar a 75 o 125 millones de registros.

Hacerlo en una sola tabla elimina todos los join de millones de registros, y
los correspondientes indices y datos duplicados para unir las tablas, pero
una sola mega tabla con cientos de campos y millones de registros me da
miedo, sobre todo en rendimiento, estabilidad , necesidad de particionar y
demas.

Según vuestra experiencia, cual sería la mejor manera de estructurarlo, en
una tabla o en tres. Y los pros y los contras.

Gracias.

GenioMaestro,

si hablamos de normalizacion, entonces una sola tabla. Hablemos ahora de
la
practica, que tan frecuente accesas la informacion de calculos y analisis
respecto a la informacion de cotizaciones?. Si la frecuencia es menor,
entonces tendras ventaja al particionar la tabla verticalmente, cuando
hablamos de lectura.


AMB

"GenioMaestro" wrote:

Hola a todos:

Tengo una duda sobre la estructura de la Base de Datos de mi Sistema de
Calculo Bursatil. Os cuento:

Sobre estructura de datos, normalizacion, entidades y limites de Sql
Server
creo saber bastante.

Al diseñar la estructura tengo tres entidades o tablas principales
clarisimas, con relacion uno a muchos, que son Mercados, Valores de esos
Mercados, y Cotizaciones de esos Valores. Hasta aqui bien, todo claro.

Ahora veamos el resto. Tengo Calculos de esas Cotizaciones en relacion
uno a
uno (1 a 1), y en la siguiente fase tengo Análisis de esas Cotizaciones,
tambien en relacion uno a uno (1 a 1), y luego Proyecciones de esas
Cotizaciones, tambien en relacion uno a uno (1 a 1).

Por análisis de entidades, son tablas distintas, pero por análisis de
normalizacion, deberia estar en una sola tabla, ya que se relacionan uno
a
uno (1 a 1).

El volumen de datos no es grande, porque casi todos los campos son money
y
tengo unos 50 o 60 campos en Calculos, 10 o 15 en Analisis y casi 300 en
Proyecciones. Lejos del limite de 1024 campos por tabla, que segun creo
permite Sql Server, y creo que tambien lejos de los 8 k'as por fila.

Pero eso si, esoy hablando de millones y millones de registros, voy por
25
millones y puedo llegar a 75 o 125 millones de registros.

Hacerlo en una sola tabla elimina todos los join de millones de
registros, y
los correspondientes indices y datos duplicados para unir las tablas,
pero
una sola mega tabla con cientos de campos y millones de registros me da
miedo, sobre todo en rendimiento, estabilidad , necesidad de particionar
y
demas.

Según vuestra experiencia, cual sería la mejor manera de estructurarlo,
en
una tabla o en tres. Y los pros y los contras.

Gracias.

Pues la frecuencia es relativa. Y como siempre, cada vez que comento algo
con vosotros me dais ideas.

De Cotizaciones se necesita el cierre continua y constantemente, el resto de
campos son accesorios, solo se ven en la pantalla de gestion, pero nunca se
hace select sobre ellos. Y así con el resto.

En Calculos solo necesito unos 10 campos de los 60, el resto son campos de
calculos intermedios.

En Analisis solo 1 o 2 campos y en Proyecciones solo 8 o 9 campos de los
cerca de 300.

Visto de esta manera, cosa que no me habia planteado hasta ahora, parece que
lo ideal serían dos tablas, una de datos intermedios que no se consultan y
otra de datos finales sobre la que se hacen los indices, las select, las
consultas...

La idea es buena según rendimiento, pero mala según normalización, porque
seguiría teniendo dos bloques 1 a 1, y mala tambien por teoría de conjuntos
o entidades, porque las rompe totalmente.

Que es lo más importante??? Rendimiento o estructura.

Todos sabemos que una aplicacion con un rendimiento bajo es practicamente
inutil, pero una aplicacion mal estructurada puede convertirse en un
monstruo inmanejable, que por las odiosas, continuas e interminables
modificaciones puede pasar de un rendimiento excelente a algo inaceptable,
todo por una tonta modificacion sobre una mala estructura.

Leches, que dificil es esto. Y ahora por donde tiro, por rendimiento o por
estructura.

"Alejandro Mesa" escribió en el
mensaje news:
> GenioMaestro,
>
> si hablamos de normalizacion, entonces una sola tabla. Hablemos ahora de
> la
> practica, que tan frecuente accesas la informacion de calculos y analisis
> respecto a la informacion de cotizaciones?. Si la frecuencia es menor,
> entonces tendras ventaja al particionar la tabla verticalmente, cuando
> hablamos de lectura.
>
>
> AMB
>
> "GenioMaestro" wrote:
>
>> Hola a todos:
>>
>> Tengo una duda sobre la estructura de la Base de Datos de mi Sistema de
>> Calculo Bursatil. Os cuento:
>>
>> Sobre estructura de datos, normalizacion, entidades y limites de Sql
>> Server
>> creo saber bastante.
>>
>> Al diseñar la estructura tengo tres entidades o tablas principales
>> clarisimas, con relacion uno a muchos, que son Mercados, Valores de esos
>> Mercados, y Cotizaciones de esos Valores. Hasta aqui bien, todo claro.
>>
>> Ahora veamos el resto. Tengo Calculos de esas Cotizaciones en relacion
>> uno a
>> uno (1 a 1), y en la siguiente fase tengo Análisis de esas Cotizaciones,
>> tambien en relacion uno a uno (1 a 1), y luego Proyecciones de esas
>> Cotizaciones, tambien en relacion uno a uno (1 a 1).
>>
>> Por análisis de entidades, son tablas distintas, pero por análisis de
>> normalizacion, deberia estar en una sola tabla, ya que se relacionan uno
>> a
>> uno (1 a 1).
>>
>> El volumen de datos no es grande, porque casi todos los campos son money
>> y
>> tengo unos 50 o 60 campos en Calculos, 10 o 15 en Analisis y casi 300 en
>> Proyecciones. Lejos del limite de 1024 campos por tabla, que segun creo
>> permite Sql Server, y creo que tambien lejos de los 8 k'as por fila.
>>
>> Pero eso si, esoy hablando de millones y millones de registros, voy por
>> 25
>> millones y puedo llegar a 75 o 125 millones de registros.
>>
>> Hacerlo en una sola tabla elimina todos los join de millones de
>> registros, y
>> los correspondientes indices y datos duplicados para unir las tablas,
>> pero
>> una sola mega tabla con cientos de campos y millones de registros me da
>> miedo, sobre todo en rendimiento, estabilidad , necesidad de particionar
>> y
>> demas.
>>
>> Según vuestra experiencia, cual sería la mejor manera de estructurarlo,
>> en
>> una tabla o en tres. Y los pros y los contras.
>>
>> Gracias.
>>
>>
>>
>>

Por análisis de entidades, son tablas distintas, pero por análisis de
normalizacion, deberia estar en una sola tabla, ya que se relacionan uno a
uno (1 a 1).

Hacerlo en una sola tabla elimina todos los join de millones de registros,

y los correspondientes indices y datos duplicados para unir las tablas,