Foreign key & references

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Foreign key & references

    Wer weiss Rat?
    Ich bin davon ausgegangen, wenn ich die ID in der table Namen lösche, daß
    auch die ID in der table Zugang gelöscht wird.
    2 Löschbefehle absetzen geht, ist aber nicht meine gesuchte Lösung.

    Code:
    drop table Zugang;
    create table if not exists Zugang (
    ID int unsigned auto_increment,
    Loginname varchar(30),
    Passwort varchar(90),
    Lastlogin TIMESTAMP,
    Primary Key (ID)
    )AUTO_INCREMENT=1;
    
    drop table Namen;
    create table if not exists Namen (
    ID int unsigned auto_increment,
    Name varchar(60),
    Vorname varchar(40),
    Gruppe varchar(60),
    Email varchar(40),
    Primary Key (ID),
    FOREIGN KEY(ID) REFERENCES Zugang(ID) ON UPDATE CASCADE ON DELETE RESTRICT
    )AUTO_INCREMENT=1;
    
    INSERT INTO Namen (Name) VALUES ("username_abc");
    INSERT INTO Zugang (Loginname) VALUES ("loginname_abc");
    select * from Namen;
    select * from Zugang;
    DELETE FROM Namen WHERE ID='1';
    select * from Namen;
    select * from Zugang;
    Vielen Dank schon mal; der
    Linuxfred

  • #2
    Hallo,

    das funktioniert nur umgekehrt: Wenn du Zugang löschst, wird auch der zugehörige Name gelöscht, der darauf verweist. Dafür musst du aber on delete cascade setzen, mit restrict verbietest du es ja.

    Edit: Im Grunde gibt es auch aus Normalisierungsgründen keinen sinnvollen Grund, das als 1:1-Beziehung abzubilden. Warum nicht alles in 1 Tabelle packen, was 1:1 zusammengehört?

    Gruß,

    Amica
    Zuletzt geändert von AmicaNoctis; 11.01.2011, 15:45.
    [COLOR="DarkSlateGray"]Hast du die [COLOR="DarkSlateGray"]Grundlagen zur Fehlersuche[/color] gelesen? Hast du Code-Tags benutzt?
    Hast du als URL oder Domain-Beispiele example.com, example.net oder example.org benutzt?
    Super, danke!
    [/COLOR]

    Kommentar


    • #3
      [QUOTE=AmicaNoctis;649966]Hallo,

      das funktioniert nur umgekehrt: Wenn du Zugang löschst, wird auch der zugehörige Name gelöscht, der darauf verweist. Dafür musst du aber on delete cascade setzen, mit restrict verbietest du es ja.

      Edit: Im Grunde gibt es auch aus Normalisierungsgründen keinen sinnvollen Grund, das als 1:1-Beziehung abzubilden.

      Warum nicht alles in 1 Tabelle packen, was 1:1 zusammengehört?
      Du weisst ja, daß ich Anfänger bin und ich dachte mir, daß alle Schüler und Lehrer die Namen, aber nicht die Passwörter und Loginname lesen müssen.
      Die dritte table, wird die table Adressen und wie wir Wissen, kann in einer Strasse mehrere Benutzer wohnen. (Naürlich kann ich auch alles in eine table "hauen"... aber ich dachte ich versuche es gleich richtig zu machen.)

      Schüler und Lehrer bekommen jeweils eine eigene table Namen.

      Verzeih meine Anfänger-IQ, aber wie sollte es genau aussehen?
      Kannst Du meine Zeilen korrigieren, damit ich sehe was Du meinst?

      Ich dachte je höher die Aufteilung um so leichter die spätere Verwaltung, oder
      Ich dachte an die spätere (viel viel später) Verwendung einer LDAP/Kerberos- Auth.
      Vielen Dank schon mal; der
      Linuxfred

      Kommentar


      • #4
        Code:
        DELETE FROM Namen WHERE ID='1';
        Namen.ID ist vom Typ INT, richtig wäre daher "WHERE ID = 1".

        Kommentar


        • #5
          Unnötige Normalisierung

          Wie schon mein Vorredner AmicaNoctis gesagt hat, ist diese Normalisierung unnötig.
          Was Du mit einer Abfrage auf die Datenbank holst, bestimmst Du über eine SQL-Abfrage. Man nehme halt nie "select * from ...", sondern gebe die entsprechenden Spaltennamen mit ein die man haben möchte. Abgesehen davon sieht ein Benutzer sowieso nur, was Du explizit auch in einem Skript zur Anzeige bestimmst.

          Aus Sicherheitsgründen sollten dann natürlich das Passwort auch nie im Originaltext stehen, sondern z.B. als md5-hash abgelegt sein. Und keine Angst, mysql schafft auch die paar zusätzlichen Spalten noch mit "vielen vielen" Dateneinträgen. Dafür sind Datenbanken ja da :-)

          Gruß Wörni

          Kommentar

          Lädt...
          X