Vistas divididas

Hola:
Vamos a ver si me expreso un poco mejor.
Hablando de la tercera opcion. SI NO EXISTE LLAVE PRIMARIA NATURAL.
(O sea si no hay una combinacion de columnas que me garantize que una fila
es diferente a la otra y que no puedan ser nulas). Agrega una columna tipo
INT (NO tiene que ser BIGINT).
Un INT permite 4 Mil Millones de filas, los positivos son 2 Mil
Millones, o sea (2000 meses)
Si lo vieramos cronologicamente, empezando de 0 filas. El CHECK el
primer mes diria: CHECK(ID>=0)
Al final del periodo, cuando se produce un nuevo mes, creas la nueva
tabla (mensual) . Y cambias el CHECK del primer mes por: CHECK (ID BETWEEN

AND 994313). Esto asumiendo que el primer periodo tuvo 994,313 movimiento.
El CHECK de la nueva Tabla seria: CHECK (ID>™4314)
Si el proximo mes (2do mes) tiene 1,050,000 movimientos entonces al
final del periodo cambio el CHECK de esta tabla y queda: CHECK (ID BETWEEN
994314 AND 2,044,313). Y el CHECK de la nueva Tabla seria

Cada vez que creas un nuevo periodo, corriges el CHECK Anterior y

la nueva tabla. Adicionalmente es posible que quieras REINDEXAR para
asegurar un mejor desempeno. En los meses anteriores usas un
FILLFACTOR/PADINDEX muy altos (100) y en la tabla nueva bien bajos.
La ventaja de este diseno sobre el del BIGINT con meses implicitos, es
de desempeno. Con un BIGINT agregar 4 bytes innecesarios, que ocupan

en la tabla haciendo la tabla mas grande, si la fila tiene 100 bytes la
aplicacion seria 4% mas lenta. Pero lo mas importante es que el Indice

del doble de largo o sea que ocupa mucho mas espacio, haciendo tambien mas
lento y mas lentos cualquier indice que lo referencie.
Normalmente no es necesario este tipo de consideraciones pero si vas a
tener Tablas con tantas filas si valen la pena. Por ultimo este es de las

opciones que te di el que menos me gusta.:(
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.
Xavi escribio:
> Hola, de entrada, gracias por contestar. No entiendo el siguiente
> comentario:
>
>> Unicamente si no es posible encontrar una llave primaria, te
>> recomendaria crear una columna Entera (no es necesario un BigInt a
>> menos que tengas mas de 2000 meses)
>
> Este campo de fecha igualmente tiene que existir, ya sea datetime o
> smalldatetime, puesto que hace referencia a la fecha del registro. Es
> indispensable. Cuando hablaba de bigint me refería a la PK. Tendría
> la PK bigint de 13 dígitos ( 4 primeros mes y año ) y 9 siguientes
> secuencial por mes/año. Igualmente, tendría el campo fecha.
>
> Las checks de cada tabla ( llamémoslas Tabla0704 ) serían del estilo
>
> ID / 1000000000 < 0804 and ID / 1000000000 >= 0704
>
> Todo esto para no tener una PK múltiple. Si la PK es múltiple,
> evidentemente la opción que planteas tú sería la más correcta.
> ¿Afecta demasiado a la inserción un check de este estilo? A menos que
> el rendimiento me penalizara mucho, seguiría con mi idea de utilizar
> una única PK.
>
> Gracias
>
> Xavi

OK, muchas gracias!

Ahora la pregunta se amplía un poco más: la verdadera razón de
utilizar una vista dividida es el crecimiento excesivo de lo que
originalmente era una sola tabla. Como tal, tenía sus relaciones e
índices.

¿Debería crear las relaciones e índices igualmente en las tablas
particionadas? Por los índices no me asusto, pero por las relaciones,
crearía un número excesivo de ellas, no?

Gracias por vuestros comentarios

Xavi


"Javier Loria" escribió en el mensaje
news:%23oghvB$

Hola:
Vamos a ver si me expreso un poco mejor.
Hablando de la tercera opcion. SI NO EXISTE LLAVE PRIMARIA
NATURAL. (O sea si no hay una combinacion de columnas que me
garantize que una fila es diferente a la otra y que no puedan ser
nulas). Agrega una columna tipo INT (NO tiene que ser BIGINT).
Un INT permite 4 Mil Millones de filas, los positivos son 2 Mil
Millones, o sea (2000 meses)
Si lo vieramos cronologicamente, empezando de 0 filas. El CHECK
el primer mes diria: CHECK(ID>=0)
Al final del periodo, cuando se produce un nuevo mes, creas la
nueva tabla (mensual) . Y cambias el CHECK del primer mes por: CHECK
(ID BETWEEN 1 AND 994313). Esto asumiendo que el primer periodo tuvo
994,313 movimiento. El CHECK de la nueva Tabla seria: CHECK
(ID>™4314) Si el proximo mes (2do mes) tiene 1,050,000
movimientos entonces al
final del periodo cambio el CHECK de esta tabla y queda: CHECK (ID
BETWEEN 994314 AND 2,044,313). Y el CHECK de la nueva Tabla seria
CHEK(ID> 44314) Cada vez que creas un nuevo periodo, corriges
el CHECK Anterior y creas la nueva tabla. Adicionalmente es posible
que quieras REINDEXAR para asegurar un mejor desempeno. En los meses
anteriores usas un FILLFACTOR/PADINDEX muy altos (100) y en la tabla
nueva bien bajos. La ventaja de este diseno sobre el del BIGINT
con meses implicitos, es
de desempeno. Con un BIGINT agregar 4 bytes innecesarios, que ocupan
espacio en la tabla haciendo la tabla mas grande, si la fila tiene
100 bytes la aplicacion seria 4% mas lenta. Pero lo mas importante
es que el Indice queda del doble de largo o sea que ocupa mucho mas
espacio, haciendo tambien mas lento y mas lentos cualquier indice
que lo referencie. Normalmente no es necesario este tipo de
consideraciones pero si vas a tener Tablas con tantas filas si valen
la pena. Por ultimo este es de las 3 opciones que te di el que menos
me gusta.:( 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.
Xavi escribio:

Hola, de entrada, gracias por contestar. No entiendo el siguiente
comentario:

Unicamente si no es posible encontrar una llave primaria, te
recomendaria crear una columna Entera (no es necesario un BigInt a
menos que tengas mas de 2000 meses)

Este campo de fecha igualmente tiene que existir, ya sea datetime o
smalldatetime, puesto que hace referencia a la fecha del registro.
Es indispensable. Cuando hablaba de bigint me refería a la PK.
Tendría
la PK bigint de 13 dígitos ( 4 primeros mes y año ) y 9 siguientes
secuencial por mes/año. Igualmente, tendría el campo fecha.

Las checks de cada tabla ( llamémoslas Tabla0704 ) serían del estilo

ID / 1000000000 < 0804 and ID / 1000000000 >= 0704

Todo esto para no tener una PK múltiple. Si la PK es múltiple,
evidentemente la opción que planteas tú sería la más correcta.
¿Afecta demasiado a la inserción un check de este estilo? A menos
que el rendimiento me penalizara mucho, seguiría con mi idea de
utilizar una única PK.

Gracias

Xavi

Hola:
Creo que si deberias crear las relaciones. Las relaciones normalmente

imponen una gran carga de desemepeno. No deberia ser mayor problema.
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.
.
Xavi escribio:
> OK, muchas gracias!
>
> Ahora la pregunta se amplía un poco más: la verdadera razón de
> utilizar una vista dividida es el crecimiento excesivo de lo que
> originalmente era una sola tabla. Como tal, tenía sus relaciones e
> índices.
>
> ¿Debería crear las relaciones e índices igualmente en las tablas
> particionadas? Por los índices no me asusto, pero por las relaciones,
> crearía un número excesivo de ellas, no?
>
> Gracias por vuestros comentarios
>
> Xavi
>
>
> "Javier Loria" escribió en el mensaje
> news:%23oghvB$
>> Hola:
>> Vamos a ver si me expreso un poco mejor.
>> Hablando de la tercera opcion. SI NO EXISTE LLAVE PRIMARIA
>> NATURAL. (O sea si no hay una combinacion de columnas que me
>> garantize que una fila es diferente a la otra y que no puedan ser
>> nulas). Agrega una columna tipo INT (NO tiene que ser BIGINT).
>> Un INT permite 4 Mil Millones de filas, los positivos son 2 Mil
>> Millones, o sea (2000 meses)
>> Si lo vieramos cronologicamente, empezando de 0 filas. El CHECK
>> el primer mes diria: CHECK(ID>=0)
>> Al final del periodo, cuando se produce un nuevo mes, creas la
>> nueva tabla (mensual) . Y cambias el CHECK del primer mes por: CHECK
>> (ID BETWEEN 1 AND 994313). Esto asumiendo que el primer periodo tuvo
>> 994,313 movimiento. El CHECK de la nueva Tabla seria: CHECK
>> (ID>™4314) Si el proximo mes (2do mes) tiene 1,050,000
>> movimientos entonces al
>> final del periodo cambio el CHECK de esta tabla y queda: CHECK (ID
>> BETWEEN 994314 AND 2,044,313). Y el CHECK de la nueva Tabla seria
>> CHEK(ID> 44314) Cada vez que creas un nuevo periodo, corriges
>> el CHECK Anterior y creas la nueva tabla. Adicionalmente es posible
>> que quieras REINDEXAR para asegurar un mejor desempeno. En los meses
>> anteriores usas un FILLFACTOR/PADINDEX muy altos (100) y en la tabla
>> nueva bien bajos. La ventaja de este diseno sobre el del BIGINT
>> con meses implicitos, es
>> de desempeno. Con un BIGINT agregar 4 bytes innecesarios, que ocupan
>> espacio en la tabla haciendo la tabla mas grande, si la fila tiene
>> 100 bytes la aplicacion seria 4% mas lenta. Pero lo mas importante
>> es que el Indice queda del doble de largo o sea que ocupa mucho mas
>> espacio, haciendo tambien mas lento y mas lentos cualquier indice
>> que lo referencie. Normalmente no es necesario este tipo de
>> consideraciones pero si vas a tener Tablas con tantas filas si valen
>> la pena. Por ultimo este es de las 3 opciones que te di el que menos
>> me gusta.:( 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.
>> Xavi escribio:
>>> Hola, de entrada, gracias por contestar. No entiendo el siguiente
>>> comentario:
>>>
>>>> Unicamente si no es posible encontrar una llave primaria, te
>>>> recomendaria crear una columna Entera (no es necesario un BigInt a
>>>> menos que tengas mas de 2000 meses)
>>>
>>> Este campo de fecha igualmente tiene que existir, ya sea datetime o
>>> smalldatetime, puesto que hace referencia a la fecha del registro.
>>> Es indispensable. Cuando hablaba de bigint me refería a la PK.
>>> Tendría
>>> la PK bigint de 13 dígitos ( 4 primeros mes y año ) y 9 siguientes
>>> secuencial por mes/año. Igualmente, tendría el campo fecha.
>>>
>>> Las checks de cada tabla ( llamémoslas Tabla0704 ) serían del estilo
>>>
>>> ID / 1000000000 < 0804 and ID / 1000000000 >= 0704
>>>
>>> Todo esto para no tener una PK múltiple. Si la PK es múltiple,
>>> evidentemente la opción que planteas tú sería la más correcta.
>>> ¿Afecta demasiado a la inserción un check de este estilo? A menos
>>> que el rendimiento me penalizara mucho, seguiría con mi idea de
>>> utilizar una única PK.
>>>
>>> Gracias
>>>
>>> Xavi