none
llave compuesta RRS feed

  • Pregunta

  • dado el siguiente script

    CREATE TABLE [dbo].peras(
    [id] [int] IDENTITY(1,1) NOT NULL,
    [idHumanResource] [int] NOT NULL,
    [name] [nvarchar](50) NOT NULL,
    [WhoTeaches] [nvarchar](100) NOT NULL,
    [WhoTitulate] [nvarchar](100) NOT NULL,
    [IsTitulate] [bit] NULL,
    [idTitleLevel] [int] NOT NULL,
    [StudyFrom] [datetime] NOT NULL,
    [StudyFromTo] [datetime] NOT NULL,
     CONSTRAINT [PK_peras] PRIMARY KEY CLUSTERED 
    (
    [id] ASC
    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
    ) ON [PRIMARY]

    que modificacion requiere para que el campo id que es autonumerico y es llave foranea siga siendo autonumerico pero que este compuesto por el autonumerico y el campo idHumanResource


    jueves, 7 de diciembre de 2017 6:35

Respuestas

  • Simplemente, añadir el segundo campo en la parte de abajo, donde construye la clave:

    CREATE TABLE [dbo].peras (
      [id] [int] IDENTITY(1,1) NOT NULL,
      [idHumanResource] [int] NOT NULL,
      [name] [nvarchar](50) NOT NULL,
      [WhoTeaches] [nvarchar](100) NOT NULL,
      [WhoTitulate] [nvarchar](100) NOT NULL,
      [IsTitulate] [bit] NULL,
      [idTitleLevel] [int] NOT NULL,
      [StudyFrom] [datetime] NOT NULL,
      [StudyFromTo] [datetime] NOT NULL,
       CONSTRAINT [PK_peras] PRIMARY KEY CLUSTERED  ( [id], [idHumanResource] )
    )


    Editado: Nótese que esto no sirve para nada. Puesto que el Id ya es un valor único por ser un Identity, ya es complétamente no-ambiguo e identifica el registro de forma unívoca, por lo que IdHumanResource no contribuye nada a la clave primaria. Este tipo de configuración solo es útil cuando el campo NO es un identity, sino que se repite para distintos valores del otro campo. Por ejemplo, cuando la clave es "número de factura + línea de factura": la línea 1 existe en todas las facturas, ya que todas numeran sus líneas empezando por la línea 1. Si la línea de factura fuera un Identity, entonces usaríamos solo ese campo como clave primaria y no añadiríamos el número de factura. Tu situación es similar: tal como lo tienes, te sobra el IdHumanResource en la clave primaria puesto que el Id ya es Identity.

    Puede tener sentido incorporar el campo IdHumanResource para que forme parte del índice con el fin de acelerar las consultas (y no porque resulte útil para la clave primaria). Pero esto solo será efectivo si lo pones en el orden contrario, es decir, ( [idHumanResource], [id] ) en lugar de ( [id], [idHumanResource] ).


    jueves, 7 de diciembre de 2017 7:55

Todas las respuestas

  • El autonumerico no se reseteará por cada idhumanresource, para eso en todo caso debes usar secuencias y manejarlo tu mismo https://docs.microsoft.com/en-us/sql/t-sql/statements/create-sequence-transact-sql para que la clave sea compuesta modifica tu script para que incluya el nuevo campo. 

    constraintpk_peraas primary key clustered ( id,idhumanresource)


    Comparte lo que sepas, aprende lo que no sepas (FGG)
    portalSQL
    El rincón del DBA

    • Propuesto como respuesta greg_dorian jueves, 7 de diciembre de 2017 13:49
    jueves, 7 de diciembre de 2017 7:52
    Moderador
  • Simplemente, añadir el segundo campo en la parte de abajo, donde construye la clave:

    CREATE TABLE [dbo].peras (
      [id] [int] IDENTITY(1,1) NOT NULL,
      [idHumanResource] [int] NOT NULL,
      [name] [nvarchar](50) NOT NULL,
      [WhoTeaches] [nvarchar](100) NOT NULL,
      [WhoTitulate] [nvarchar](100) NOT NULL,
      [IsTitulate] [bit] NULL,
      [idTitleLevel] [int] NOT NULL,
      [StudyFrom] [datetime] NOT NULL,
      [StudyFromTo] [datetime] NOT NULL,
       CONSTRAINT [PK_peras] PRIMARY KEY CLUSTERED  ( [id], [idHumanResource] )
    )


    Editado: Nótese que esto no sirve para nada. Puesto que el Id ya es un valor único por ser un Identity, ya es complétamente no-ambiguo e identifica el registro de forma unívoca, por lo que IdHumanResource no contribuye nada a la clave primaria. Este tipo de configuración solo es útil cuando el campo NO es un identity, sino que se repite para distintos valores del otro campo. Por ejemplo, cuando la clave es "número de factura + línea de factura": la línea 1 existe en todas las facturas, ya que todas numeran sus líneas empezando por la línea 1. Si la línea de factura fuera un Identity, entonces usaríamos solo ese campo como clave primaria y no añadiríamos el número de factura. Tu situación es similar: tal como lo tienes, te sobra el IdHumanResource en la clave primaria puesto que el Id ya es Identity.

    Puede tener sentido incorporar el campo IdHumanResource para que forme parte del índice con el fin de acelerar las consultas (y no porque resulte útil para la clave primaria). Pero esto solo será efectivo si lo pones en el orden contrario, es decir, ( [idHumanResource], [id] ) en lugar de ( [id], [idHumanResource] ).


    jueves, 7 de diciembre de 2017 7:55