Consulta sencilla

Si la tabla tendrá unos 20,000 regs.. lo mejor es que ninguna de esas sea
llave PK Clustered.
sino que crees una columna identity.. o rowguid.

saludos

"qwalgrande" escribió en el mensaje
news:

Hola.

Aunque depende de la forma en la que vayas a explotar luego la
información, lo suyo es que tu clave primaria y también tu índice
clustered sea el campo COD_ARTICULO, indexando, si procede, el otro campo.
En todo caso, si va a ser realmente frecuente buscar por familia, puedes
incluirlo en el índice clustered.

Muchas gracias por responder tan claramente.

Otra duda que me surge:
A la hora de realizar un pedido y determinar el artículo a incluir en
ese pedido deberás de realizar una busqueda.
Tengo una serie de campos :
cod_articulo,cod_familia,descricpion,cod_proveedor,neto y otros campos
menos revelantes.
Teniendo en cuenta que decido que cada articulo se identifique por el
cod_articulo.
Que campo/s se usarían para realizar la busqueda del artículo a meter en
el pedido.

Ya se que es una pregunta un poco general, pero mi idea es realizar el
filtro por el campo proveedor y el campo descricpcion para acotar la
busqueda; sería una burrada?. Teniendo en cuenta que la tabla tendria
tantos registros.


"Alejandro Mesa" escribió en el
mensaje news:

David,

Dejame aclarar algo. La clave primaria es una restriccion de tipo

conceptual

(parte de la teoria de bases de datos relacionales) y cada tabla debe

tener

una independiente de como sql server la implemente. SQL Server 2000 lo

hace

creando un indice unico que por defecto es clustered si este no se
especifica. Asi que decirte cual clave primaria escojer sin mas

informacion

sobre tu negocio no creo que sea algo adecuado. Que tal si tu compania

emite

el mismo cod_articulo para diferentes cod_familia?, en ese caso la clave
primaria esta compuesta por ambas columnas, de lo contrario, creo que el
cod_articulo es suficiente como clave primaria. Ahora, si quieres

implementar

la clave primaria mediante el uso de un indice unico clustered o
nonclustered, entonces debes primero analyzar que tipo de quieries

estarias

usando contra esa tabla.

El indice clustered debe ser lo mas estrecho posible (cantidad de bytes en
la clave) y casi siempre se escojen columnas las cuales se usan en las
clausulas "order by", "group by" o que se usan en filtros de rangos. Si

esta

columna ademas crece monoliticamente (por ejemplo una columna identity)
entonces estarias evitando particionamiento de paginas, pero corres el

riesgo

de ocasionar "hot spot" (mucha actividad en una zona especifica del disco)

si

el numero de transacciones por segundo supera las 1000. Siempre es bueno

que

una tabla tenga un indice clustered y como se puede tener solo 1, entonces
debes escojer las columnas que mas se beneficien de el.

En cambio, los indices nonclustered se usan principalmente para

identificar

grupos pequenios de filas (si la clave es unique mejor) y se escojen en
dependencia de los queries, principalmente las columnas que participan en

la

clausula "where". Que sql server los use o no, depende de la distribucion

de

los valores en las columnas que conforman la clave del indice, el tipo de
expresion que uses en el filtro y el costo asociado al uso de ese indice.

Te recomiendo leas los BOL, asi como los articulos relacionados con

indices

que aparecen en este link. Tambien te recomiendo el libro "inside sql

server

2000" escrito por Kalen Delaney.

SQL Server Performance Tuning Tips
http://www.sql-server-performance.c...rmance.asp

Microsoft SQL Server 2000 - A Fondo

http://www.amazon.com/gp/product/844813155X/qid34764955/sr=8-2/ref=sr_8_xs_ap_i2_xgl14/002-9210940-5312032?nP7846&s=books&v=glance

AMB


"David Caballero" wrote:

> Hola buenas tardes:
>
> Tengo una tabla de articulos, pregunta sencilla :
> Que es mejor tener de primaria key:
> 1- Dos campos COD_ARTICULO, COD_FAMILIA
> 2.- Un campo unico COD_ARTICULO (el campo
> cod_familia estaria en la tabla tambien)
>
> Mi duda es para posteriormente optimizar el rendimiento en

busquedas,

> teniendo en cuenta que esa tabla tendra unos 20.000 registros.
>
> Muchas Gracias
>
>
>
>