longitud máxima de un indice

[Euro Nava]

Hola amigos en la versión 9.0 de Fox ¿cual es la longitud máxima permitida que puede tener un campo indice alfanumérico?

saludos 

[Analyzer]

Si los índices "no compactos" que menciona el enlace fueran los cdx ... serían 100 bytes.

http://msdn.microsoft.com/en-us/library/3kfd3hw9(v=vs.80).aspx

Porque acerca de los compactos la ayuda dice:

Compact Index File Structure (.idx)

Saludos!

[Luis Maria Guayan]

Para que no te dejes confundir con Foxito:

Visual FoxPro Index File Types

Index file type	Description	Contains	Limits
Structural compound index (.cdx) files	Opens and closes with the table automatically. Uses same base name as the table file name.	Multiple index keys	240-character limit on evaluated expression
Nonstructural compound index (.cdx) files	Must be opened explicitly. Uses a name different from the base table name and is defined by the user.	Multiple index keys	240-character limit on evaluated expression
Standalone index (.idx) files	Must be opened explicitly. Uses a name different from the base table name and is defined by the user.	Single index key	100-character limit on evaluated expression

Luis María Guayán
Tucumán, Argentina
_________________________
http://www.PortalFox.com
Nada corre como un zorro
_________________________

[Analyzer]

Oooooooo.. Ni tanto..  Apenas y fallé por 240 jeje

Pero ya fuera de broma.. el enlace ese de MS no menciona los "compound" ( compuestos ).

Solo los compact y los non-compact.. entonces..

IF compact=Compact Index File Structure (.idx) , cuales son los no compactos que soportan 100 bytes ? ..

No sé ustedes pero para mí esto es un error claro en la documentación de VFP.

¿ A quién le vamos a creer de las 2 fuentes ? ¿Un volado o un tin marín?..

Saludos!

2013/5/3 Luis Maria Guayan <luism...@gmail.com>

[Euro J. Nava L.]

En conclusión ¿la longitud máxima para los índices tipo CDX es de 240 bytes?

 

 

Saludos

 

 

 

El presente correo y sus anexos son exclusivamente para el uso de los destinatarios indicados en el encabezado del mismo, pueden contener información confidencial y/o privilegiada. Si usted por error ha recibido la presente correspondencia agradezco hacer omisión de esta y hacerme del conocimiento por esta misma vía.

 

Bendito el hombre que ha sido llamado por Cristo para ser soldado de su ejército en cuya mano empuñe como arma la palabra de Dios

---

Se certificó que el correo no contiene virus.
Comprobada por AVG - www.avg.es
Versión: 10.0.1432 / Base de datos de virus: 3162/5793 - Fecha de la versión: 03/05/2013

[Luis Maria Guayan]

Asi es, Foxito siempre confunde

Luis María Guayán
Tucumán, Argentina
_________________________
http://www.PortalFox.com
Nada corre como un zorro
_________________________

[Euro J. Nava L.]

Confunde… pero como es de bueno

 

Gracias Don Luis Maria y amigo Analyzer por su ayuda

 

 

Saludos

 

 

El presente correo y sus anexos son exclusivamente para el uso de los destinatarios indicados en el encabezado del mismo, pueden contener información confidencial y/o privilegiada. Si usted por error ha recibido la presente correspondencia agradezco hacer omisión de esta y hacerme del conocimiento por esta misma vía.

 

Bendito el hombre que ha sido llamado por Cristo para ser soldado de su ejército en cuya mano empuñe como arma la palabra de Dios

 

Versión: 10.0.1432 / Base de datos de virus: 3162/5796 - Fecha de la versión: 04/05/2013

[Carlos Miguel FARIAS]

Los indices de VFP están montados sobre una estructura árbol B+.

Cada hoja del árbol ocupa unos 1000 bytes. Un árbol B+ tiene en sus nodos claves y punteros a las inferiores y nodos anteriores y siguientes o a datos. Los datos se ubican en un archivo plano (dbf) y se agregan naturalmente al final del archivo.

Cada puntero ocupa 4 bytes (es un entero) de donde sale el límite de los 2 GB de direccionamiento.

Si la clave es alfanumérica, como dijeron, la longitud máxima es 240, si la clave es numérica ocupa 8 bytes independientemente del tamaño del campo o expresión numérica en la que se base.

Por eso, a las claves numéricas es aconsejable convertirlas con CTOBIN y BINTOC para que al convertirse el numero en caracteres binarios, cada clave ocupará 4 bytes.

Por qué debo preocuparme de ello?

Porque cuando más claves punteros entran en un nodo del árbol b+ del índice, más rápido es el funcionamiento del acceso por indice (al azar o secuencial) por la sencilla razón de que el índice es más pequeño y rushmore busca a través de los indices, y cuando se busca a través de la red, lo primero que se pasan son los indices, por lo que se reduce el trafico de red.

Independientemente de ello, todos los SGBD (o al menos la mayoría) utilizan el mismo tipo de indices para indexar sus propias tablas.

Diferente son los indices cluster (racimo) de SQL Server (no es exclusivo). Allí, los datos se acomodan en nodos en el orden del indice, y sobre dichos nodos, hay una estructura también arbórea. La ventaja de los indices cluster es que tienen un acceso menos al disco al buscar, pero ralentizan el tiempo de inserción.
Como ventaja, pueden tener registros de longitud variable, y no fija como vfp.

En general, en cualquier SGBD, conviene que los indices sean lo más pequeños posibles, y que las claves primarias no deban modificarse.

Por ejemplo, en mis modelos, prácticamente todas las claves primarias son mono-campo, enteros, sin signo, y auto-incrementales (no en VFP, que es más lento), de manera tal que, si en la clave "primaria" natural (que sería UNIQUE en los SGBD y candidata en VFP), hay errores en carga, solo modifico esa clave y no tengo que propagar los cambios a las tablas relacionadas.

Saludos: Miguel, La Pampa (RA)

[Fernando D. Bozzo]

Impresionante explicación Miguel,

Gracias!

[Carlos Miguel FARIAS]

Omiti indicar que en el caso de los indices tipo cluster, el acceso secuencial ordenado por el indice cluster es muy rápido, porque los datos estan ya ubicados en ese orden.

Teoricamente, conviene tener el indice cluster ordenado por la clave que se usa para consultas ordenadas (por ejemplo, en tabla clientes, ordenada por nombre de cliente en lugar de por su número, porque el sistema recupera los datos en consultas por nombre en forma inmediata.

Por supuesto, eso hay que sopesarlo porque en ese caso, el idcliente (clave primaria) sería más lenta en las consultas de un cliente en particular o si la tabla de clientes entra en muchos joins (donde no se ordenan datos por cliente).

Por supuesto, siempre recuerden que al diseñar un modelo de datos, hay 6 reglas básicas para seleccionar la estructura de datos a utilizar.

a) Reducir al máximo el volumen de datos.

b) Optimizar en Función de Frecuencia y Modo de Uso.
c) Tener en cuenta datos estáticos o dinámicos.

d) Tener en cuenta espacio necesario para una estructura de datos en particular.

e) Tener en cuenta el tiempo de respuesta de la estructura

f) Ver que algoritmo simplifica la programación.

Estas cosas se fundamentan en que:

a) Una buena normalización de datos, evita redundancia, inconsistencia de datos, reduciendo el volumen de datos sobremanera y cualquier opración ulterior.

Además se debe tener en cuenta que los campos no deben sobredimensionarse. Por ejemplo, si se que nunca tendré más de 10000 clientes. Un campo clave primario de 2 bytes (smallint en mysql) sería más que suficiente. Eso reduce 2 bytes en cada cliente (poco?) pero reduce 2 bytes en cada tabla que tenga como clave foránea cliente (facturas, pedidos, remitos, notas de crédito y débito, etc.) y en el espacio requerido por cada indice.

b) Los datos y la estructuras debe responder a como se van a usar (modo), si no responden a eso, se crea una complejidad enorme para luego resolver por programa lo que la estructura (mal diseñada) no logra resolver solo con su forma. También se tiene que tener en cuenta la frecuencia como se usan los datos  o los modos de acceso. Por ejemplo, si mis accesos son permanentemente al azar (modo), y con alta frecuencia, el acceso hashing es el más indicado, (se puede hacer con tablas nativas), muy dificil en tablas en un sgbd.

c) Algunos diseños, son muy útiles cuando los datos son estáticos (no se modifican o se modifican propio). Por ejemplo en un entorno VFP, conviene tener las tablas nativas (y diría hasta con un SGBD central), puede ser más eficiente tener los datos estáticos en datos locales, antes que en el servidor.

Por ejemplo: Los datos de ciudades y provincias, es muy dificil que permanentemente se modifiquen, por lo que si, se necesita mucho acceso (para validar o para consultar), posiblemente sea mucho más eficiente tener los datos descriptivos localmente que en el servidor.

Los datos dinámicos (altas, bajas y modificaciones frecuentes), deben hacerse con más recaudo.

d) Aunque actualmente, preocuparme por el espacio en disco disponible puede ser poco "significativo", hay que tener en cuenta que minimizar el espacio requerido por la estructura de datos de acceso (p.e. los indices) sigue siendo bueno, porque todo lo que se pequeño, los SGBD los meten en memoria RAM (principal), y eso mejora mucho el desempeño. En el ejemplo que di en a) el cambio en el tamaño de la clave principal (de 4 a 2 bytes) que parece ser ridicula en la tabla principal, calculen el ahorro al propagarse a los datos (ya comentado) y los respectivos indices foráneos. En disco seguiría siendo rídiculo, pero en memoria RAM, posiblemente no.

Y además indices más chicos, reducen la cantidad de accesos al disco, en el ejemplo, la cantidad de accesos al disco para buscar un registro se reduce al menos a la mitad, y facilmente, 4 veces menos. (Si, podrán decir que con los nuevos discos fijos -RAM- eso es circunstancial, pero la diferencia, no es tan dificil de lograr).

e) En este punto, si todavia quedan alternativas, habrá que ver que tipos de acceso pueden usarse para mejorar los tiempos, dependerá de las estructuras disponibles en este punto.

f) Y por último, si todavia no pudieron determinar una estructura ganadora, elijan la que más les guste, conozcan o sepan usar. Pero eso si, si empiezan por aca, lo más probable que el diseño sea una porqueria.

Este ordenamiento (que no es invento mio, está sacado de bibliografía sobre estructura de datos), tiene ese orden, porque cada paso, ayuda al que sigue al momento lograr el objetivo de cada paso.

Una BD normalizada correctamente (regla a]), responde perfectamente a los modos de uso, y un modelo mas simple, es mas fácil de "frecuentar".
A su vez, si el modelo responde a modo y frecuencia (si no, no sirve), el punto de estático y dinámico, ayuda en los puntos subsiguientes.

Si la estructura es pequeña, generalmente, ante iguales requerimientos, es mas veloz.

Si no es veloz, no sirve de nada que sea fácil de programar.

Si no la sabes programar, ESTUDIA, que la ignorancia, es la estructura mas lenta que hay (NO SABES como resultará)

Saludos: Miguel, La Pampa (RA)

El 5 de mayo de 2013 20:17, Fernando D. Bozzo <fdb...@gmail.com> escribió:

Impresionante explicación Miguel,

Gracias!

[Luis Maria Guayan]

Muy interesantes tus dos envios. Gracias.

Luis María Guayán
Tucumán, Argentina
_________________________
http://www.PortalFox.com
Nada corre como un zorro
_________________________

[Arnaldo Toledano]

Muy buena su alocucion PROFE.

Me hace suponer que debes ser un PROFESOR muy didáctico.
Gracias


Arnaldo Toledano

--
Arnaldo Toledano Tesys Informática Córdoba Argentina

[Fernando D. Bozzo]

Magistral! Esto debería estar en la ayuda de cualquier bdd, como conocimientos generales.

Gracias!

[Carlos Miguel FARIAS]

Para llegar a mi máxima capacidad docente, solo me faltan 10 años más de práctica, después me jubilo.

Y uno aprende, después de 33 años dando clase, hay que ser muy inútil, uno aprende, vio? Hay que aprender de los propios errores, aceptar la crítica constructiva y saber porque hay de la otra.

Lo más importante para ser buen docente, es saber porque no se le entiende, o sea en que falla por deficiencia propia, o en que falla por el contexto (estudiantes con mala preparación, entorno de clases inapropiado, etc). Y una vez detectado el problema, buscar una solución.

O sea, el buen docente, es aquel que todavía sigue siendo buen estudiante.

No debe olvidarse que siempre uno es estudiante, porque nadie sabe todo.

Si fuera viernes diría, si hay algo que nadie sabe, pregunta sin miedo que nadie responde!

Saludos: Miguel, La Pampa (RA)

[Daniel Sánchez]

Es muy interesante y didactico lo que compartio el compañero Carlos Farias.

Saludos

[Luis la Romana]

Veo que algunos usan un lector de news para postear en este foro (Mozilla TB, etc) ¿cómo lo hacen?

[Geovanny Buenaño]

Estimado Miguel, mientras buscaba la solución a un problema de índices estructurales (CDX) encontré este foro, el cual se relaciona con lo que busco.  Tus respuestas me parecen muy buenas, sin embargo, creo que algo está mal con VFP, pues cuando utilizo una clave compuesta por 5 campos tipo caracter(30) Fox me muestra el mensaje "La longitud de clave no es válida"; cuando intento con 4 campos recibo el mismo error, cuando lo hago con 3 campos o cuando cambio la longitud del cuarto campo a 10 caracteres SI lo permite.   He realizado varias pruebas tanto VFP6 como en VFP8 y siempre los mismos resultados.  Hice una nueva prueba creando una tabla de prueba en Foxpro para windows 2.6 e intenté indexar, y SI permitió crear el CDX con los cinco campos.  En base a lo mencionado estoy por concluir (a menos que tengas alguna explicación), que foxpro 2.6 permite 240 caracteres como límite mientras las versiones posteriores solo 100 caracteres a nivel de indices estructurales CDX.

Por favor si sabes que se lo que puede estar pasando por favor házmelo saber.

Muchas gracias

Geovanny

[edgar suarez kummers]

Tienes bastante paciencia, te esperaste dos años para contestar.

Yo quiero un "mensajero" así para mi final en este mundo, que sea de color "morado".

Edgar Suárez Kummers

[Fernando D. Bozzo]

Hola Geovanny:

Los índices de VFP 9 funcionan bien y admiten 240 caracteres, de hecho algunos los uso con ese límite.

¿Podrías poner un ejemplo de creación de tablas y de índice que no te permite hacer? Me refiero a algo del tipo:

CREATE TABLE xxx (campo1 tipo, campo2 tipo, etc)
INDEX ON xxxx


Creo que el problema puede estar en cómo lo estés haciendo o alguna configuración de la tabla.

Saludos.-

[edgar suarez kummers]

Buenas Fernando:

Creo que se refieren a tablas creadas manualmente y con índices principales y candidatos. No tengo instalado VFP9.0, pero un ensayo colocando un campo STRING de 240 bytes y principal y de pronto otro campo de 240 bytes y candidato. Debo salir a acompañar a mi esposa. Bye.

saludos

 

Edgar Suárez Kummers

[Ricardo Peña]

Notable.
 
Con File, new, table ( menú ) creé una tabla con 2 campos a y b de 240 caracteres.
En el mismo momento creo un índice por el campo a y me da invalid key length.
Le hago modify structure y me deja crear el mismo índice todo ok.
 
Salu2.

Ricardo Luis Peña
Analista de Sistemas
BA - Argentina
011-15-4440-7378
 

---

From: edgark...@gmail.com
Date: Thu, 19 Feb 2015 19:08:37 -0500
Subject: Re: [vfp] longitud máxima de un indice
To: publice...@googlegroups.com

[edgar suarez kummers]

Felicitaciones Ricardo.

Sí recordaba algo de problema en esas key's de 240 caracteres.

Ya lo solucionaste

Gracias.

Edgar Suárez Kummers

[Carlos Miguel FARIAS]

Una clave de 240 caracteres? Bueno, es cuestión de gustos.

Si solo usas letras (alfabeto ingles) y números son 36 caracteres distintos.

O sea, solo dispones de:

32553687050529924940022327064252765334085528845763241866742075807229245167752472487284264825974274875608078445029431970658369442834071070007737959196759170909516830740382927526890819761417669639090777049834362819299733472828870202817488065531066478967942294406544449820375720292823679156751946309767349134933295326680449440506968894561334433342371885567435438891494618955776

Claves posibles, realmente, para que te puede alcanzar?

El calculo lo hice con python, son 374 dígitos enteros y puede más probé con 100**100000 y se las aguantó son más de 200000 dígitos, realmente, no se cual es el límite (dicen que depende del procesador)

Saludos: Miguel, La Pampa (RA)

[Fernando D. Bozzo]

Hola Miguel:

Seguro que no se te ocurre para qué puede servir usar una clave tan larga porque hoy es viernes :D

Pero te dejo un ejemplo:
FoxUnit usa ese tamaño de clave para poder ordenar por TestClass+TestName que como verás no son códigos, sino nombres descriptivos :)

(por cierto, esta modificación la hice yo y la envié al autor para soportar nombres en español, ya que en inglés no tienen problema con la longitud:)

[Carlos Miguel FARIAS]

Hace como 25 años desarrolle un algoritmo que manejaba indices con claves de longitud, teóricamente infinita. Como no había facilidades de publicación quedo en el olvido. Las pruebas que hice me daban que el procesamiento era más rápido que en dbase (la relación era +/- 1' en dbase, 4" con mi algoritmo)

Y si controlaste los cálculos que pase, te habrás dado cuenta que por ser viernes, les estaba tomando el pelo (aunque los cálculos son correctos).

Por otro lado, veo que los nombres utilizados son poco apropiados, incluir preposiciones y artículos es martirio para el programador.

El castellano escrito implica el doble de longitud que el ingles, no viste que cuando pasan una serie que esta originalmente en ingles, te dicen "doblado al español..."

pero solo los viernes. ;-D

Saludos: Miguel; La Pampa (RA)