Erstellen einer Tabelle mit untergeordnetem Increment und vielleicht cleveren Defaults

  • SQL

Es gibt 2 Antworten in diesem Thema. Der letzte Beitrag () ist von Haudruferzappeltnoch.

    Erstellen einer Tabelle mit untergeordnetem Increment und vielleicht cleveren Defaults

    Hallo,

    ich erstelle eine kleine Hilfstabelle für die Erstellung von Text.
    Dabei wäre mir ganz lieb auch ein paar Grundprinzipien zu nutzen und zu verstehen bei der Verwendung von Datenbanken.

    Ich nutze MSSQL. Hier erstmal der Erstellcode der Tabelle, wie ich sie jetzt habe (Teilweise ist der automatisch durch das Studio erzeugt):

    SQL-Abfrage

    1. CREATE TABLE [dbo].[FormTextBaustein](
    2. [Typ] [tinyint] NOT NULL,
    3. [Typbeschreibung] [varchar](50) NOT NULL,
    4. [LfdNr] [int] Identity,
    5. [Baustein] [varchar](150) NOT NULL,
    6. [Beschreibung] [varchar](50) NOT NULL,
    7. [Variablen] [varchar](100) NOT NULL,
    8. PRIMARY KEY CLUSTERED
    9. (
    10. [Typ] ASC,
    11. [LfdNr] ASC
    12. )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
    13. ) ON [PRIMARY]

    Mit dem Verständnis, dass der Key gleichzeitig der Clustered Index für die Tabelle sein wird, möchte ich die Spalte Typ definitiv als erste Schlüsselspalte wählen, da alle WHERE Clauses nahezu ausschließlich nach dieser Spalte suchen werden. Da ein Key aber Unique sein muss, brauche ich eine weitere Spalte und da denke ich bot sich nur an eine automatische Nummerierung zu verwenden (LfdNr). Diese Nummer zählt aber nicht pro Typ-Wert hoch, sondern generell.

    Gibt es auch eine Identity-Variante, die sich einer anderen Spalte unterordnet?
    Also statt jeden Eintrag durchzuzählen, nur die jeweiligen Einträge gleichen Typs durchzählen. Oder wäre das garnicht sinnvoll bzw. sogar schädlich?

    Außerdem habe ich eine Spalte Typbeschreibung, diese korrespondiert ja mit der Spalte Typ, also wo *Typ gleich ist ist auch Typbeschreibung gleich.
    Kann man da eine Art Default drauflegen, der sich nach der Spalte Typ unterscheidet? Der Sinn darin wäre, dass so sichergestellt ist, dass * auch wirklich stimmt.

    Viele Grüße

    Haudruferzappeltnoch schrieb:

    Gibt es auch eine Identity-Variante, die sich einer anderen Spalte unterordnet?
    Soweitichweiss nicht.

    Haudruferzappeltnoch schrieb:

    Oder wäre das garnicht sinnvoll?
    Mit Identity - also AutoIncrement wohl eher nicht sinnvoll.
    Aber du kannst ja einen normalen Integer nehmen, und deine eigene Auto-Increment-Logik schreiben. Da muss dann auch geklärt sein, wie mit Löschungen umgegangen wird - werden dann die IDs umnummeriert - damit die lfdNr wirklich eine laufende Nummer ist?
    Das kannste auch auf der Datenbank machen, in einem hinterlegten Trigger - Geht ratzfatz - in nur 2 Tagen Arbeit hast du geschafft, was sowieso und ohne das auch schon funktioniertete ;) .
    Und alle Coder, die das später lesen müssen, werden beeindruckt sein :thumbup:

    Haudruferzappeltnoch schrieb:

    Außerdem habe ich eine Spalte Typbeschreibung, diese korrespondiert ja mit der Spalte Typ, also wo *Typ gleich ist ist auch Typbeschreibung gleich.
    Kann man da eine Art Default drauflegen, der sich nach der Spalte Typ unterscheidet? Der Sinn darin wäre, dass so sichergestellt ist, dass * auch wirklich stimmt.
    Das scheint mir FehlDesign.
    Die Typbeschreibung soll in einer Tabelle Typ sein, auf die verwiesen wird.

    Aber das sind so die grundlegenden Prinzipien, die ich immer als erstes propagiere. Ohne Ironie: In Praxis kann davon abzuweichen auch mal Sinn machen.

    Stimmt, das verhält sich wie ein Fremdschlüssel. Damit spare ich sogar Datenvolumen, weil die TypTabelle jeden Typ nur einmal enthält.

    SQL-Abfrage

    1. CREATE TABLE [dbo].[FormTextTyp](
    2. [Typ] [tinyint] NOT NULL,
    3. [Typbeschreibung] [varchar](50) NOT NULL,
    4. PRIMARY KEY CLUSTERED
    5. (
    6. [Typ] ASC
    7. )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
    8. ) ON [PRIMARY]
    10. CREATE TABLE [dbo].[FormTextBaustein](
    11. [Typ] [tinyint] NOT NULL,
    12. [LfdNr] [int] Identity,
    13. [Baustein] [varchar](150) NOT NULL,
    14. [Beschreibung] [varchar](50) NOT NULL,
    15. [Variablen] [varchar](100) NOT NULL,
    16. CONSTRAINTS FK_FormTextBaustein_FormTextTyp FOREIGN KEY (Typ) REFERENCES FormTextTyp (Typ) ON DELETE CASCADE ON UPDATE CASCADE
    17. PRIMARY KEY CLUSTERED
    18. (
    19. [Typ] ASC,
    20. [LfdNr] ASC
    21. )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
    22. ) ON [PRIMARY]


    Gut die LfdNr behält die Reihenfolge innerhalb des Typs trotzdem bei, daher kann man damit wohl auch leben.

Facebook
Telefonspende