SQL Server Tabelle mit Bedingungen



  • Ich möchte Geräteanschlüsse verwalten. Abhängig vom Anschluss gibt es weiter Einstellungen. Hat ein Gerät zb einen seriellen Anschluss können dafür noch vereschiedene Dinge mit konfiguriert werden.
    Hat ein Gerät einen usb Anschluss gibt es diese Möglichkeit nicht.

    Meine Idee war es jetzt das ich eine Tabelle mit den versch. Anschlussarten habe und eine weitere mit den Einstellungen.

    An der Stelle habe ich mir überlegt wie ich sicher sein kann das nicht usb und com eingetragen wird.
    Ich weiß gar nicht ob das irgendwie Sinn macht, aber da dachte ich halt wenn
    usb -> com = null

    Edit: ich hatte bisher nicht wirklich mit Datenbanke zu tun

    Edit2 So sieht jetzt mal grob die Tabellenstuktur aus

    ---------------	---------------
    Anschlusart		Anschlus
    --------------- -------------
    1 | usb			1| usb1 
    2 | com		        1| usb2       ....
    3 | tcp
     
     
    ----------
    Settings
    ---------
    1| setting1 -- gehört zu usb1


  • Habe auch gerade solch ein Problem im Studium. Bin gespannt auf das Ergebnis! Thx für jede Hilfe!! 😊



  • Wenn du das wirklich machen willst, dann so mit SQL CONSTRAINT CHECK
    Ich bin kein SQL Experte, aber so müsste man es machen, wenn das Einfügen (oder Ändern...) von Einträgen consistency checks erfüllen müssen.

    Das hier macht dass ein Device mit Spalte usb und Spalte com, eins von beiden haben muss, aber nicht beide.
    könnte für dein Fall etwas komplizierter werden.

    CREATE TABLE Device
    (
        /*...*/
        CONSTRAINT myConstraint CHECK 
        ((com IS NULL AND usb IS NOT NULL) OR
        (com IS NOT NULL AND usb IS NULL))
    )
    


  • @5cript Hey das sieht ja schon gut aus. Danke :). An welche Stelle pack ich das dann, hinter die Spaltendefinition?



  • @Liz

    Ich würds persönlich ganz hinter alle Spaltendefinitionen schreiben.



  • @5cript Top Danke



  • usb1 / usb2 ist doch redundant.
    Ich würde das bisher gesagte so auf drei Tabellen aufteilen:

    Tabelle Anschlussart:

    Nr   Beschreibung
    1    USB
    2    COM
    3    TCP
    ...
    

    Tabelle Anschluss:

    Anschlussart  Nr
    1             1
    1             2
    1             3
    2             1
    2             2
    ...
    

    Tabelle Settings:

    Anschlussart Nr Settings
    1            1  Settings für USB1
    1            2  Settings für USB2
    2            1  Settings für COM1
    ...
    

    Dann benötigt man bis hierher erst mal gar keine nullfähigen Spalten.



  • @Belli auch vielen Dank für deine Antwort. Habs jetzt so ähnlich auch umgesetzt



  • So habe ichs jetzt umgesetzt:

    Tabelle Anschluss (ID, Beschreibung)

    ID Beschreibung
    1  usb
    2  com
    3  com
    ...
    

    Tabelle com (fk_anschluss references Anschluss (ID))

    ID  Setting1   Setting2 ...
    2  'Setting1' 'Setting2' ...
    ...
    

    Das selbe für die Anderen Anschlüsse auch. Da ich so ja nicht verhindern kann das in der com Tabelle zb was mit der ID 1 eingetragen wird. Hab ich mir ein Constraint check zusammengebaut wo ich prüfe ob ID UND Bezeichnung in der Anschlusstablelle existieren.

    create function fnCheckID (@Input varchar(45), @id int)
    
    returns bit
    
    AS
    begin
      declare @Val varchar(45)
      declare @RetVal bit
    
      select @Val = (select type from Connection c
    	where c.idConnection = @id and
    	c.type = @Input)
    
    if (@Val is not null)
    	set @RetVal = 1
    else 
      set @RetVal = 0
    
    return @RetVal
      end
    

    Ist vielleicht etwas umständlich, aber funktioniert soweit.

    ABER:
    Wird die Bezeichnung in der Tabelle Anschlussart jetzt verändert, dann passts natürlich nicht mehr.
    Gibt es die Möglichkeit so ein Constraint in beide Richtungen zu machen? Vielleicht weiß ja einer von euch was.

    lg Liz

    Edit
    Ich glaube ich machs mir da viel zu komlpiziert. Nehme ich die Beschreibung auch noch als Fremdschlüssel in der com Tabelle auf, dann umgehe ich das Problem der inkosistenz. Richtig?



  • Dieser Beitrag wurde gelöscht!

Anmelden zum Antworten