Creacion de Indice para optimizar tabla para busqueda por apellidos y nombres

[mabarcau]

Mis estimados, tengo una tabla de clientes que por ahora cuenta con
alrededor de 100 mil registros, y el tamaño se incrementara
rapidamente, tengo un campo codigo cliente nvarchar(13), pero por lo
general las busquedas que se realizan son por apellidos y nombres,
como saben los usuarios mayormente escriben fracciones de dichos
campos, a veces la primera letra tan solo, el primer apellido, lo caul
hace que el tiempo de consulta sea extremadamente extenso, mi pregunta
es, que recomendarian que haga para optimizar las consultas que de por
si van a tomar su tiempo.

Les adjunto la estructura de mi tabla de clientes.

CodCliente varchar 13
TipoPersona int 4
ApellidoPaterno varchar 30
ApellidoMaterno varchar 30
ApellidoCasada varchar 30
Nombre varchar 30
Sexo char 1
EstadoCivil varchar 2
NroHijos int 4
Residente bit 1
RazonSocial varchar 100
Siglas varchar 30
TipoEmpresa varchar 2
PaginaWeb varchar 75
FechaNacimiento varchar 8
CodPais varchar 3
TelefonoDomicilio varchar 30
TelefonoCelular varchar 30
TelefonoTrabajo varchar 30
TelefonoReferencia varchar 30
Fax varchar 15
EmailPersonal varchar 40
EmailTrabajo varchar 40
CodCIIU varchar 5
CodSBS varchar 10
CalificacionSBS int 4
CondicionLaboral int 4
EmpresaGiroLaboral varchar 25
Observacion nvarchar 500
Estado int 4
FechaRegistro varchar 25
FechaActualizacion varchar 25

Cualquier sugerencia que venga de parte de ustedes, sera por demas
agradecida de mi parte, aca les envio un ejemplo de busqueda.

caso ideal:
exec PERSONA_Get_Nombre @vchApellidoPaterno = 'ramos',
@vchApellidoMaterno = 'sajami', @vchApellidoCasada = '', @vchNombre =
'marlon', @intIndEstado = 0

caso real:
exec PERSONA_Get_Nombre @vchApellidoPaterno = 'r', @vchApellidoMaterno
= 's', @vchApellidoCasada = '', @vchNombre = '', @intIndEstado = 0

Como veran, solo consultan con las iniciales.
Pendiente de ustedes, me despido.

Saludos Cordiales,

Miguel

[Luis Mata]

Mira yo predije que iba a pasar eso en mi sistema así que procedí a trabajar
con temporales, creo temporales en cada PC cliente, las tablas de mayor uso:
digamos clientes, artículos, proveedores y otros.
luego la búsqueda la hago en una tabla local osea en los temporales, cuando
la encuentre en código envía al servidor dicho código y extrae los datos
restantes y las muestra al usuario.
y adicionalmente en mi pantalla principal creo un procedimiento que compare
los datos de cada tabla temporal con la de la base de datos original y las
vaya actualizando.
pues así evite que mi sistema se vuelva un poco chancha.
En mi caso uso VFP 9 con DBF como temporales con SQL 2005

Luis Mata
Perú

"mabarcau" <maba...@gmail.com> escribió en el mensaje
news:d7cca200-4a13-47c6...@u10g2000prn.googlegroups.com...

[Alejandro Mesa]

mabarcau,

Yo haria una prueba creando los sgtes indices:

1 - ApellidoPaterno
2 - ApellidoMaterno
3 - ApellidoCasada
4 - Nombre
5 - (Nombre, ApellidoPaterno, ApellidoMaterno)
6 - (Nombre, ApellidoCasada)

Para las opciones 5 y 6, preferible que uses como columna guia (primera
columna en el indice) aquella que tenga menor numero de duplicados para que
el indice sea mas selectivo.

Las opciones 1 - 4, te ayudarán en las consultas donde solo se usa una de
estas columnas, mientras que las opciones 5 y 6 te ayudaran en las consultas
donde se usan mas de una columna en el criterio. Para que los indices 5 y 6
sean usados, la columna guia debe estar siempre presente en la busqueda
aunque no se tenga una valor explicito para ella.

Ejemplo:

...
where nombre like '%' and ApellidoCasada like 'mejorsoltera%'

...
where nombre = 'Angela' and ApellidoMaterno like 'Garc%'

...
where nombre = 'Angela' and ApellidoPaterno like 'Rodri%'

...
where nombre = 'Angela' and ApellidoPaterno like 'Rodri%' and
ApellidoMaterno like 'Garc%'

Aca el indice multicolumnas no sera usado por no usar la columna guia.
...
where ApellidoPaterno like 'Rodri%' and ApellidoMaterno like 'Garc%'

Para las consultas tipo:

columna like '%patron'

o

columna like '%patron%'

No esperes el mismo desempeño que las consultas que no usan el caracter '%'
al principio.

En SQL Server 2005, existe una nuevo valor de estadistica sobre la
distribucion de ciertas subcadenas dentro de un indice de cadena, el cual
ayuda al optimizador de queries cuando se usa este tipo de busquedas
'%patron%'. El optimizador puede decidir si hacer un scan del indice
nonclustered seguido por una operacion bookmark lookup o escanear la tabla /
indice clustered. Previo a SQL Server 2005, no se tenia esta estadistica y
por ende el optimizador siempre obtava por escanear la tabla / indice
clustered (o el mismo nonclustered si este es cubierto - covered index)

USE [AdventureWorks]
GO

DBCC SHOW_STATISTICS ('Person.Contact', 'IX_Contact_EmailAddress') WITH
STAT_HEADER
GO

Fijense en la ultima columna del resultado (String Index - YES).

SET SHOWPLAN_TEXT ON
GO

SELECT ContactID, FirstName, LastName, EmailAddress
FROM Person.Contact
WHERE EmailAddress LIKE N'%d19%'

SELECT ContactID, FirstName, LastName, EmailAddress
FROM Person.Contact
WHERE EmailAddress LIKE N'%son%'
GO

SET SHOWPLAN_TEXT OFF
GO

|--Nested Loops(Inner Join, OUTER
REFERENCES:([AdventureWorks].[Person].[Contact].[ContactID]))
|--Index
Scan(OBJECT:([AdventureWorks].[Person].[Contact].[IX_Contact_EmailAddress]),
WHERE:([AdventureWorks].[Person].[Contact].[EmailAddress] like N'%d19%'))
|--Clustered Index
Seek(OBJECT:([AdventureWorks].[Person].[Contact].[PK_Contact_ContactID]),
SEEK:([AdventureWorks].[Person].[Contact].[ContactID]=[AdventureWorks].[Person].[Contact].[ContactID])
LOOKUP ORDERED FORWARD)

|--Clustered Index
Scan(OBJECT:([AdventureWorks].[Person].[Contact].[PK_Contact_ContactID]),
WHERE:([AdventureWorks].[Person].[Contact].[EmailAddress] like N'%son%'))

Noten que para la primera sentencia, el optimizador decide hacer un scan del
indice:

[AdventureWorks].[Person].[Contact].[IX_Contact_EmailAddress]

seguido por una operacion bookmark lookup en el indice clustered. Esto se
debe a que el optimizador sabe el numero de filas que machan el criterio, en
este caso 20 (pueden verlo si escojen ver el plan estimado), por lo que
escanear el indice nonclustered (que es mas estrcho y por ende mas rapido de
leer) y hacer una busqueda usando index seek en el indice clustered, es mas
optimo que escanear todo el indice clustered y preguntar en cada fila si esta
cumple el criterio. En la segunda sentencia el optimizador estima que 356
filas machan el criterio y prefiere escanear el indice clustered a escanear
el nonclustered y luego hacer bookmark lookup.

AMB

[Luis Tarzia]

Siempre en el server la busqueda es mas rapida que en un temporal en la pc
del cliente.
Y las actualizaciones en tiempo real ??
Y el tiempo que se toma en traer toda la tabla a temporal ????
El like con el full text seach es la solucion.
"Luis Mata" <lm...@hipermercadoceramico.com.pe> escribió en el mensaje
news:#zhLU9Zd...@TK2MSFTNGP02.phx.gbl...

[Luis Mata]

Mira en mis caso, los temporales estan en la raiz c: del cliente digamos en
el caso de la tabla cliente tengo un id esto lleva el conteo de clientes
actuales lo unico que hago es comparar los ids de ambas tablas si del server
es mayor solo traigo la diferencia en registros.
a mi me sirve mucho esto ya que mi sistema trabaja con VPN y son redes
fisicamente separados por muchos kilometros y mi tabla cliente tienes
185,000 registros te imaginas lo que significaria llevar y traer esa
informacion por cada consulta?, por eso opte por los temporales.

Luis
Peru

"Luis Tarzia" <tarzi...@ciudad.com.ar> escribió en el mensaje
news:OuaqKcwd...@TK2MSFTNGP05.phx.gbl...