Ilja: MS SQL 2008 R2 Identity spalten

moin,

muss mich mal wieder mit einem MS SQL Datenbank server rumschlagen, befinde mich sozusagen auf fremden gebiet. was ich brauche sind zwei Spalten, die automatisch befüllt werden, der primary key über eine IDENTITY spalte und noch eine weitere spalte. das problem ist, dass es nur eine spalte mit der IDENTITY eigenschaft geben kann oder liege ich da falsch? gibt es einen anderen weg, die andere spalte ebenfalls automatisch vom system befüllen zu lassen (trigger erst mal aussen vor gelassen) ?

Ilja

  1. Hi Ilja!

    Ich nehme an, du brauchst das aus gutem Grund. So ganz erschliesst sich mir der Sinn nämlich nicht. =)

    In MS SQL gibt es NEWSEQUENTIALID() und NEWID(), mit denen du allerdings "nur" GUIDs automatisch erzeugen kannst. Diese Funktionen können natürlich auch als DEFAULT-Parameter für Attribute angegeben werden.

    CREATE TABLE test (  
      id INTEGER PRIMARY KEY IDENTITY,  
      id2 UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID(),  
      -- ...  
    );
    

    Fortlaufende Zahlen wirst du über Trigger oder Stored Procedures erzeugen müssen. Je nachdem in welchem Zusammenhang id2 mit id steht, könnte man auch über eine berechnete Spalte nachdenken.
    Wobei folgendes CREATE-Statement mMn reichlich sinnfrei ist:

    CREATE TABLE test (  
      id INTEGER PRIMARY KEY IDENTITY,  
      id2 AS (id),  
      -- ...  
    );
    

    MfG H☼psel

    --
    "It's amazing I won. I was running against peace, prosperity, and incumbency."
    George W. Bush speaking to Swedish Prime Minister unaware a live television camera was still rolling, June 14, 2001
    Selfcode: ie:% fl:( br:> va:) ls:& fo:) rl:? n4:& ss:| de:] js:| ch:? sh:( mo:) zu:)
    1. moin Hopsel,

      Ich nehme an, du brauchst das aus gutem Grund. So ganz erschliesst sich mir der Sinn nämlich nicht. =)

      jup, ist eine grundsätzliche regel, keine fachlichkeit in primärschlüsseln, hat sich immer wieder bewährt. was ich neben dem künstlichen schlüssel brauche, ist eben ein fachlicher schlüssel, das kann man sich zum beispiel als namen für einen geschäftspartner vorstellen, der eindeutig (und not null) sein muss und sprechend ist. nur in diesem falle brauche ich eben einen automatisch erzeugten fachlichen schlüssel.

      In MS SQL gibt es NEWSEQUENTIALID() und NEWID(), mit denen du allerdings "nur" GUIDs automatisch erzeugen kannst. Diese Funktionen können natürlich auch als DEFAULT-Parameter für Attribute angegeben werden.

      CREATE TABLE test (

      id INTEGER PRIMARY KEY IDENTITY,
        id2 UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID(),
        -- ...
      );

        
      dank für den hinweis und ich habe das mal ausprobiert, grundsätzlich ok von der funktionalität, er macht das, was ich eigentlich will, aber die inhalte sind doch recht "unschön", wenn man das als techniker überhaupt sagen darf, ohne ausgelacht zu werden....  
        
      
      > Fortlaufende Zahlen wirst du über Trigger oder Stored Procedures erzeugen müssen. Je nachdem in welchem Zusammenhang id2 mit id steht, könnte man auch über eine berechnete Spalte nachdenken.  
      > Wobei folgendes CREATE-Statement mMn reichlich sinnfrei ist:  
      > ~~~sql
      
      CREATE TABLE test (  
      
      >   id INTEGER PRIMARY KEY IDENTITY,  
      >   id2 AS (id),  
      >   -- ...  
      > );
      
      

      ich denke auf den trigger wird es bei MS SQL wohl hinaus laufen, wird zeit, dass die endlich mal sequenzen einführen.  und auch wenn das schräg aussieht, ich bin sogar geneigt das mit dem id2 AS (id) für das erste zu übernehmen. es mögen die gleichen inhalte sein, aber da kann ich nur meinen bewährten daten-design merksatz entgegen halten,was gleich aussieht,muss nicht das selbe sein....

      auf jeden fall erst mal danke für die anregungen, vielleicht kommen ja noch welche hinzu.

      Ilja

      1. Hi,

        mit etwas "Magie" kann man sich "Sequenzen" selbst bauen, sogar mit Transaktions-Unterstützung. Stichwort CLR, custom type und einer "backing table" ...

        Btw: id2 AS (id) ... in der Klammer kannst du ziemlich viel anstellen mit der id ... das Keyword "PERSISTED" dahinter sorgt dafür dass bei einem neuen Record (in dem Fall auch neuem Identity-Wert) der berechnete Wert physikalisch abgespeichert wird und damit indizier bar. Bedingung: Funktion muss "deterministisch" sein.

        Cheers, Frank

        1. moin,

          mit etwas "Magie" kann man sich "Sequenzen" selbst bauen, sogar mit Transaktions-Unterstützung. Stichwort CLR, custom type und einer "backing table" ...

          dafür ist im moment leider keine zeit und ich würde mir wünschen, ms sql würde das von hause aus bieten. und ich muss zugeben, ich werde immer skeptischer gegenüber den ms sql server, mir fehlen einfch viele liebgewonne funktionalitäten aus oracle und das kostet alles viel zeit sich einzuarbeiten. naja, vielleicht auch ein wenig: was der bauer nicht kennt, das isst er nicht....

          Btw: id2 AS (id) ... in der Klammer kannst du ziemlich viel anstellen mit der id ... das Keyword "PERSISTED" dahinter sorgt dafür dass bei einem neuen Record (in dem Fall auch neuem Identity-Wert) der berechnete Wert physikalisch abgespeichert wird und damit indizier bar.

          jup, habe ich auch erst mal so gemacht (persisted), gross berechnet wird da nichts, der wert wird 1:1 so übernommen. warum jetzt ms sql nicht erlaubt mehrfache identity spalten zuzulassen, dass entzieht sich noch meinem verständnis.

          Ilja

          1. Servus

            warum jetzt ms sql nicht erlaubt mehrfache identity spalten zuzulassen, dass entzieht sich noch meinem verständnis.

            Vielleicht um Schizophrenie vorzubeugen? Mehrere Identitäten für dasselbe Objekt und so .... Wer oder was bin ich und wenn ja, wie viele?

            Mir ist im übrigen noch nie (in den letzten 10 Jahren) ein Fall untergekommen, wo ich mehrere Identity Spalten in einer Tabelle gebraucht hätte.

            Sequenzen empfände ich auch als natürliche Evolution. Aber anscheinend gab es bislang nicht genügend Interessenten als das Mickeysoft es zu einem Produktfeature von SQL Server gemacht hätte.

            Cheers, Frank