MySQL - Mejor campo para Indices

   
Vista:

Mejor campo para Indices

Publicado por Lord Voldemort (6 intervenciones) el 21/12/2011 17:05:16
Hola..

Tengo una dudilla......

toda mi vida he usado campos ID tipo numericos y autonumericos... para los campos llaves
pero herede un sistema que me toco mantenerlo y junto al mio lo he manejado y lo que pude hacer para estrar entre las dos bases de datos fue usar "codigos" entre las bases.. el codigo que en la otra base de datos era un texto de 16 caracteres, pues ni modo use un campo tipo CHAR de 16 caracteres tambien en mi bd, en fin.. la pregunta es esta...
hay desventaja tener un indice tipo CHAR con respecto a usar un tipo NUMERICO?

saludos
Valora esta pregunta
Me gusta: Está pregunta es útil y esta claraNo me gusta: Está pregunta no esta clara o no es útil
0
Responder

Mejor campo para Indices

Publicado por Gonzalo GC (339 intervenciones) el 22/12/2011 01:45:44
En realidad, el mejor tipo de clave primaria (supongo que al decir índices, te refieres a ellas), son las que surgen de la entidad que se está representando en la tabla, y no necesariamente un indice numérico ni incremental.
El modelo relacional no habla jamás de campos numéricos cuando se menciona las PK, sino de atributos o conjuntos de atributos que permiten identificar unívocamente un registro en una tabla. Pero eso no quiere decir que deban ser numéricos.
Una persona, por ejemplo, es identificable de muchas formas: por su nombre y apellido, por su filiación, por su generos, o por todos estos elementos al mismo tiempo. De ello se desprende que puede identificarse por una PK creada en base a un conjunto de datos al mismo tiempo, ya que cada uno de ellos, por separado, no puede hacerlo.
Por supuesto que en el mundo real, los sistemas de identificación de personas evolucionaron y resolvieron el problema hace mucho tiempo, tanto por la creación de los registros civiles unificados, como por el uso de un documento único de identificación a nivel país. Si lo meditas, una persona, en realidad se identifica pos su numero de documento. Que sea incremental, es irrelevante. Lo que nos interesa en ese caso es que es único.
Ahora bien, la mejor clave es, entonces, un valor o conjunto de valores que a existan entre los campos de la tabla, y solo se deben fabricar identificadores (del tipo que sean) si luego de normalizar (ver Normalización de Bases de Datos) la tabla hasta la 3FN no se ha llegado a una clave candidata.
Poner identificadores numericos y autoincrementales es propio de programadores, no de diseñadores de datos. Son fáciles, simples de programar, pero adolecen de una enorme cantidad de problemas en cuanto quieres expandir la base: Traen problemas de migración, de respaldo, de restauración de datos y de consolidación de origenes.
Como no identifican el objeto contenido en el registro, si no el orden de entrada, no son funcionales cuando necesitas realizar consultas complejas, y terminan siendo más obstáculo que ventaja.
Sintetizando:
- Las PK numéricas autoincrementales son una pésima idea.
- Las mejores PK e índices se logran con datos propios de la tabla.
- La programación de la aplicación se hace más exigente, pero los resultado de las consultas mejoran la performance.
- Tienen mejor capacidad para integrar datos, restaurar backups, y consolidar registros históricos, porque no dependen del valor de un número sino de la identidad del objeto.

Finalmente: Si estos conceptos te causan confusión, necesitas volver a los apuntes y repasar los fundamentos de las bases de datos, en especial el paradigma Entidad-Relación.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Mejor campo para Indices

Publicado por Lord Voldemort (6 intervenciones) el 22/12/2011 14:59:51
Hola Gonzalo

Gracias por tu excelente explicación, aunque no me resolvió la pregunta porque no la expuse bien, sin embargo me has abierto un mejor panorama sobre el concepto de las llaves primarias, es para tomarlo en cuenta, muy pero muy bueno.

Ahora bien si tengo.
Tabla facturas PK NoFactura tipo CHAR
Tabla factura_detalle fkNoFactura tipo CHAR

o
Tabla facturas PK NoFactura tipo Integer
Tabla factura_detalle fkNoFactura tipo Integer

al hacer consultas, a mi motor le es indiferente que tipo de campo este usando?


saludos y gracias por todo...
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Mejor campo para Indices

Publicado por Gonzalo GC (339 intervenciones) el 23/12/2011 02:49:31
El tema de que si es CHAR() o INT, debes decidirlo en base al tipo de datos que vas a guardar. Si ese dato será numérico, debes si o si guardarlo como INT.
Si y sólo si el dato es alfanumérico (letras y/o numeros) deberás guardarlo como CHAR. En ningún otro caso.
Hay muchas razones para esto, pero la básica es que si ordenas un CHAR, lo ordenará alfabéticamente, por lo que una lista ordenada de numeros guardados en un campo CHAR te daría este resultado:

1
10
11
13
1000
1188
2
3
34
38
38678
39
¿Están mal ordenados? No. Estan correctamente ordenados... en base a su orden alfabético.

¿Se entiende el problema?

Esto causa muchos inconvenientes a la hora de una consulta.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Mejor campo para Indices

Publicado por Lord Voldemort (6 intervenciones) el 23/12/2011 17:12:50
Que tal Gonzalo? muy buenas..

No hay ningun problema con el tema de ordenar datos numericos o alfanumericos

solo ando buscando sobre que es mas "rapido" para mysql

okis mas un saludo
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Mejor campo para Indices

Publicado por Gonzalo GC (339 intervenciones) el 24/12/2011 02:54:28
Si tu pregunta apunta a qué es más rápido, si comparar numeros o caracteres, técnicamente es comparar números. Pero eso no quiere decir que a nivel de consultas comparar IDs numéricos sea más rápido que comparar IDs de caracteres. No es lo mismo el uso de la UAL (unidad aritmético-lógica) del microporcesador, que la lógica de la optimización de consultas. Están relacionadas, pero no son lo mismo.
Cuando realizas las consultas, lo mejor es ajustarse a lo que es mejor para el diseño. El usar CHAR o INT es irrelevante si llegado el caso, el ID numérico no se necesita como dato.
Me explico: Si el ID no es un dato que luego se muestra, sólo usa espacio de memoria en la consulta, lo que implica que se necesitan más bloques de memoria para obtener la misma información. Y a nivel de performance, mientras menos bloques se necesiten, más rápida será la consulta.
Quiero que te quede claro este un concepto: No importa si es INT o CHAR, lo que es relevante es el impacto que tiene esa PK en el uso del buffer de datos y en los bloques de datos leidos en memoria. SI el dato no se usa, es dato basura y se paga con performance. Por eso si la PK es un atributo que se requiere es más eficiente, aunque la comparación sea más lenta, porque lo que pierdes en ese punto lo ganas en datos recuperados. Por eso definir una PK con los propios atributos de la entidad es siempre la mejor opción, de ese modo la consulta por PK devuelve siempre datos útiles.
Si te pones a preocupar por qué es lo más "rápido" en determinadas tareas, en lugar de los más eficiente a nivel de consultas, estás poniendo el carro delante de los caballos.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Mejor campo para Indices

Publicado por Lord Voldemort (6 intervenciones) el 29/12/2011 16:05:44
Muchas Gracias Gonzalo por tu tiempo he aprendido mucho...

saludos desde Honduras
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Mejor campo para Indices

Publicado por Rafay (1 intervención) el 13/08/2015 21:09:48
Pensando en el pais de las maravillas y de un mundo feliz, donde los usuarios de los sistemas no cometieran errores, y los datos que capturan estan completamente correctos si funcionaran(los humanos nos equivocamos), supongamos que la pk son los campos nombre,paterno,nacimiento al capturar a una persona con error en nombre, al buscar la persona con los datos correctos nos indicara que no existe por lo tanto nos permitira capturar a dicha persona (validando que si una persona ya existe antes por codigo, ademas de la restriccion de no poder capturar una llave duplicada en bd), en todo caso si quieres modificar los campos de la clave principal (los grandes dioses de las bd afirman que una llave no debe modificarse) y ya tienes relaciones con otras tablas tendras que modificar todas esas otras tablas, cuando con las pk automumericas o numericas solo modificas el registro y la clave sigue siendo la misma, o si uno de los campos de la clave no se cuenta, o debe estar nulo ,etc
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar