none
Duda con llave autonumerica RRS feed

  • Pregunta

  • Buenas noches,

    Tengo una pregunta bastante básica pero que me trae con muchas dudas, en mi base de datos tengo una tabla que es para almacenar el empleo del cliente, actualmente el sistema maneja un empleo por cliente, y mi tabla está de esta forma:

    IdEmpleo //Llave primaria
    IdCliente //Llave foranea

    y el resto de campos, como comenté antes, el sistema maneja un empleo por cliente, pero sin embargo he colocado el IdEmpleo como un campo autoincremental porque no me siento muy comodo usando una relación de uno a uno, además que pasaría si en el futuro se quisiera agregar 2 empleos por cliente por eso también he dejado el IdEmpleo como llave primaria, es válido dejarlo de esta forma? o la llave primaria forzosamente debe de ser el IdCliente?


    Carlos Márquez

    viernes, 3 de octubre de 2014 3:36

Respuestas

  • Ahora mismo te da igual porque solo habrá un registro tanto si buscas por IdCliente como si buscas por IdEmpleo. Pero piensa que hemos dejado esta estructura en previsión de que alguna vez haya más de un empleo por cliente. En ese caso, cuando vayas a modificar, habrá que buscar por IdEmpleo, que identificará el registro de forma unívoca, mientras que si lo buscases por IdCliente podría encontrarte más de un registro, con lo que podrías estar modificando el registro equivocado.

    ¡Acuérdate de poner un índice sobre el campo IdCliente! (Sobre el IdEmpleo no es necesario ya que se trata de la clave primaria, y recibe un índice de manera automática).

    • Marcado como respuesta Carlos Márquez viernes, 3 de octubre de 2014 16:59
    viernes, 3 de octubre de 2014 15:29

Todas las respuestas

  • Si tienes la intención de que en el futuro pueda haber dos empleos por cliente, entonces está bien como has hecho: se utiliza el IdEmpleo como llave primaria y el IdCliente como clave externa para enlazar con la tabla de clientes.

    Si pusieras el IdCliente como llave primaria, entonces no podrías tener dos empleos por cliente. Y en ese caso te sobraría el IdEmpleo.

    viernes, 3 de octubre de 2014 5:41
  • Hola, Alberto.

    Qué pasa si tengo mi IdCliente como llave primaria? sería una relación uno a uno, correcto? podría en ese caso IdCliente ser mi llave primaria y mi llave foránea a la vez? colocar el mismo campo como ambas claves?


    Carlos Márquez

    viernes, 3 de octubre de 2014 10:25
  • Sí, es lícito que el IdCliente sea a la vez clave primaria y clave foránea, dando lugar a una relacion de 1 a (0,1). Es decir, en la tabla de clientes podría haber un cliente que no tenga registro en la tabla de empleos, pero si lo tiene ha de ser único.

    En estos casos merece la pena plantearse si merece la pena meter el IdEmpleo en una tabla aparte, o si sería más eficiente meter un campo IdEmpleo en la tabla de clientes. El IdEmpleo podría ser NULL y SPARSE (si se prevee que la mayor parte de los clientes lo tengan vacío), con lo que no estorbaría casi nada en la tabla de clientes.

    Lo de separar los datos a otra tabla con relación de 1 a 1 normalmente solo tiene sentido cuando es un registro muy ancho, y se quiere reducir por eficiencia dejando en una de las tablas únicamente los campos que se consultan con más frecuencia.

    viernes, 3 de octubre de 2014 11:04
  • Hola, Alberto.

    Usted que me recomienda? Puedo dejar la tabla Empleo tal como la tengo? es decir

    IdEmpleo //Llave primaria
    IdCliente //Llave foranea

    Muy posiblemente el cliente solo tenga un empleo pero si es así pues no pasa nada, no?

    Es decir podría conservar la relación tal como está, de 1 a muchos, aunque como comenté antes, posiblemente solo tenga un empleo, posiblemente también no tenga empleo, digo, si queda así como que tendrá mas sentido a nivel de diseño y bueno ayuda por si en el futuro el negocio quiere llevar registros de los clientes con mas de un empleo,

    Qué piensa?


    Carlos Márquez



    viernes, 3 de octubre de 2014 11:22
  • Sí, tiene sentido dejar la tabla como está en previsión de que en algún momento se decida meter más de un empleo por cliente. Con esta estructura de datos se podrá dar soporte a esa funcionalidad sin requerir cambios en el esquema.
    viernes, 3 de octubre de 2014 14:57
  • Hola, Alberto.

    Última pregunta, la búsqueda del registro empleo en la aplicación yo lo hago por medio del IdCliente, la actualización del empleo la puedo hacer por medio del IdCliente, o debo primero buscar el IdEmpleo por medio del IdCliente y actualizar con el IdEmpleo?

    Gracias por responder.


    Carlos Márquez

    viernes, 3 de octubre de 2014 15:20
  • Ahora mismo te da igual porque solo habrá un registro tanto si buscas por IdCliente como si buscas por IdEmpleo. Pero piensa que hemos dejado esta estructura en previsión de que alguna vez haya más de un empleo por cliente. En ese caso, cuando vayas a modificar, habrá que buscar por IdEmpleo, que identificará el registro de forma unívoca, mientras que si lo buscases por IdCliente podría encontrarte más de un registro, con lo que podrías estar modificando el registro equivocado.

    ¡Acuérdate de poner un índice sobre el campo IdCliente! (Sobre el IdEmpleo no es necesario ya que se trata de la clave primaria, y recibe un índice de manera automática).

    • Marcado como respuesta Carlos Márquez viernes, 3 de octubre de 2014 16:59
    viernes, 3 de octubre de 2014 15:29