Rendimiento de busquedas

[pollin14]

Hola a todos!

Eh estado pensando en el rendimiento de la base datos al utilizar distintos tipos de PRIMARY KEY o ID.

El escenario es el siguiente: Una aplicacion para una tiendita escrita en Java y utilizando MySql como sistema de persistencia.

Ahora. Hay dos formas obvias para definir el ID de cada producto, una de ellas es usar el UPC (codigo de barras), el cual en su forma mas general es una cadena. La otra es usando AUTOINCREMENT para crear un ID numerico.

¿Cual de los dos daría mejor rendimiento? Yo afirmo que el númerico, ya que es mas facil hacer una busqueda sobre numeros que sobre cadenas.

Eh visto libros de Best practices in Data Bases pero por tiempo no eh podido leer ninguno.

Espero algunos consejos. Saludos!

[gnzsoloyo]

¿Vas a tener millones de registros insertados por día?
Si la respuesta es NO, usa el UPC, tiene mayores ventajas, especialmente porque es universalmente único.
Si la respuesta es SI, puedes pensar en el autoincremental, ero a mi me sigue sin parecer una buena idea (es un parche), porque a la larga tienes problemas con las migraciones y los backups.

[pollin14]

Hola! gnzsoloyo

Como es una tienda, la mayoría de las operaciones de inserción se realizarian una unica vez (solo para llenar la base de datos). Así que la mayoría de las operaciones serian de consulta (select).

¿que ventajas tendria usar el UPC? hay UPC que son al alfanumericos por lo cual sería una la PRIMARY KEY sería una string. Porque si el UPC es un numero, no abría duda en utilizarlo como PRIMARY KEY. Eso me queda claro.

[gnzsoloyo]

El UPC es un identificador completo, es un atributo propio de la entidad, y un dato importante en los procesos de ABM, procesos de stock, peticiones de productos, etc.
Esto quiere decir, que cuando usas el UPC en un sistema lo usas siempre, para todas las tareas que involucre el producto asociado.
¿Y el ID numérico?
Bien gracias. No sirve absolutamente para nada más que identificar el registro en esa tabla.

A lo que me refiero es que en el contexto del uso a nivel de sistemas, el UPC resulta mucho más util que un ID inventado, porque está relacionado con todas las operatorias del sistema que afecten a productos. Por tanto siempre lo estarás consultando, manipulando o lo que seaa.
Además, como es un código de barras, jamás será ingresado por medios manuales, lo que evita los errores que se pueden dar con el otro ID (errores humanos).
Adicionalmente, como en la tabla de productos, el UPC debe ser también unico, tendrás que tener un índice UNIQUE sobre esa columna, con lo que en realidad tendrás una PK numérica y una clave primaria alternativa, ambas con las mismas restricciones.... o se que te sobrará una.
Yo sacrificaría la ID autoincremental, porque presenta menos utilidad.

[pollin14]

Tienes razon, el UPC, es utilizado para todo y por si mismo es un ID. Además al agregar un ID autoincremental aumentariamos el tamaño de la base de datos.

Estoy pensado en la siguiente situacion:

Supongamos que, tenemos el UPC y a parte un ID numerico (generado de alguna manera).

Entonces, realizamos una busqueda por, digamos, 10 productos. Esta busqueda sera por UPC. Una ves que tengamos lo productos realizamos una venta por lo cual hay que actualizar el campo STOCK de los 10 registros. Para hacer esto podemos hacer dos cosas:
1.- Realizar el UPDATE utilizando el UPC (una nueva busqueda) ó
2.- Realizar el UPDATE utilizando el ID (un acceso directo, como tablas hash).

Entonces, el segundo UPDATE seria mas eficiente que el segundo.

Lo que no se, es si mysql o hsqldb o cualquier otra base de datos funcionarian así. Es decir, o como busqueda o como tabla has.

[gnzsoloyo]

1.- Realizar el UPDATE utilizando el UPC (una nueva busqueda) ó
2.- Realizar el UPDATE utilizando el ID (un acceso directo, como tablas hash).

Lo importante es la PK. Si el UPC está usado como PK, el acceso es directo. La lectura del índice PRIMARY es binaria.
Si el ID es numerico, con un indice UNIQUE, el acceso es directo, si es INDEX, el acceso es por hash. Si no tiene indice definido, es un tablescan basado en el orden de la PK.
No lograrás mejoras notorias teniendo los dos campos. LO único que tendrás en una baja de performance con los ABMS.

Respecto a cómo lo implementa cada DBMS, es algo que tienes que consultar con el manual de referencia de cada una. No hay otro camino.

[pollin14]

Logre sacar estas concluciones:

Usar el UPC (tipo string) como primary key y crear un indice para mejorar el rendimiento de la Base de Datos.

Saludos!