Aliase

Spaltennamen ändern

Wir müssen uns auch mit den Spaltennamen befassen. Ansonsten wiederholen wir die Namen name und id, sie enthalten jedoch unterschiedliche Daten. Andererseits gibt es die erste Spalte „id“ und die Spalte „employee_id“, die die gleichen Daten enthalten.

Schreiben wir eine Abfrage, in der nur die erforderlichen Spalten vorhanden sind, und benennen Sie auch die Spalten mit denselben Namen um:

SELECT  
    task.id AS task_id,  
    task.name AS task_desc, 
    task.deadline AS deadline, 
    emploee.id AS emploee_id,  
    emploee.name AS emp_name,  
emploee.occupation AS	
    emp_occupation 
FROM employee, task
WHERE emploee.id = task.emploee_id

Und das Ergebnis dieser Abfrage:

Super, das Problem mit unverständlichen Spaltennamen wurde erfolgreich gelöst. Die Abfrage ist etwas lang geworden, aber in der resultierenden Tabelle ist alles klar. Und keine zusätzlichen Spalten.

Tabellenaliase

Manchmal sind Tabellennamen zu lang und nehmen viel Platz in der Abfrage ein. Um die Lesbarkeit zu verbessern, haben die Entwickler von SQL daher, wie bei Spalten, die Möglichkeit geboten, Tabellenaliase anzugeben.

Die allgemeine Form von Aliasnamen (Tabellenaliasnamen) lautet wie folgt:

FROM table1 alias1, table2 alias2

Schreiben wir unsere vorherige Abfrage mit kurzen Aliasnamen um:

SELECT  
    t.id AS task_id,  
    t.name AS task_desc, 
    t.deadline AS deadline, 
    e.id AS emploee_id,  
    e.name AS emp_name,  
    e.occupation AS emp_occupation 
    FROM employee e, task t 
WHERE e.id = t.emploee_id

Die Lesbarkeit hat leicht abgenommen, was aber daran liegt, dass die Namen der Tabellen zunächst einfach und klar waren. Es könnte genauso gut so sein:

SELECT  
  	task.id AS task_id,  
  	task.name AS task_desc, 
  	task.deadline AS deadline, 
  	emploee.id AS emploee_id,  
  	emploee.name AS emp_name,  
emploee.occupation AS	
  	emp_occupation 
FROM  
  	Microsoft_it_department_employee employee, 
  	Year2022_priority_task task 
WHERE emploee.id = task.emploee_id 

Und in diesem Fall sind Aliase schon nützlich, oder? ;)

Primärschlüssel

Und noch eine wichtige Information zu Tabellen. Erinnern Sie sich, dass wir in der Aufgabentabelle eine Spalte „employee_id“ hatten? Damit haben wir auf die Mitarbeiter-ID aus der Mitarbeitertabelle verwiesen.

Wenn wir von einer Tabelle auf die Zeilen einer anderen Tabelle verweisen möchten, muss die referenzierte Tabelle eine Spalte mit einer ID haben, die auch als Primärschlüssel bezeichnet wird – PRIMARY KEY .

Meistens handelt es sich dabei um eine speziell hinzugefügte Spalte, deren Werttyp int ist . Beim Hinzufügen von Datensätzen zu einer Tabelle legt SQL automatisch den Wert dieser Spalte fest.

Dann sind viele Dinge an diese Schlüssel gebunden:

• verschiedene Tabellen miteinander verknüpfen;
• schnelle Suche und Filterung nach ID;
• Datenintegrität in der Datenbank (keine Verweise auf nicht vorhandene ID);
• Löschen von Daten, auf die sich niemand bezieht;
• und viele viele andere.

Übrigens gibt es Situationen, in denen eine Tabelle einen sogenannten natürlichen Schlüssel hat . Dies ist der Fall, wenn es eine Spalte gibt, deren Inhalt Eindeutigkeit impliziert. Beispielsweise haben wir beschlossen, der Mitarbeitertabelle Folgendes hinzuzufügen:

• Die Reihenfolge ihres Eintreffens im Unternehmen;
• Steuernummer;
• Nummer und Serie des Reisepasses.

Manchmal verwenden Datenbankdesigner einen natürlichen Schlüssel als Primärschlüssel, meistens werden sie jedoch separat verwendet. Schließlich können Datensätze gelöscht, geändert und dergleichen werden.

Ich nehme an, Sie haben Geschichten im Internet gelesen, in denen Gerichtsvollzieher einer Person Schulden seines vollständigen Namens aufhängen? Dies hängt lediglich mit dem Konzept eines eindeutigen Schlüssels zusammen. Für Banken und Gerichtsvollzieher ist es sehr praktisch, eine Person anhand des vollständigen Namens und des Geburtsjahres zu suchen. Und in 99 % der Fälle reicht dies aus, um eine Person zu identifizieren.

Aber die restlichen <1 % sind vollständige Namensvetter mit demselben Geburtsjahr. Im Leben eines jeden von uns gibt es höchstwahrscheinlich keine solchen Menschen, aber auf nationaler Ebene gibt es sie. Wenn Sie Software schreiben oder eine Datenbank entwerfen, ist es im Allgemeinen hilfreich zu wissen, dass dies auch der Fall sein kann.