Mehrere MySQL Tabellen durchsuchen

[Devon]

Da bin ich gerade am überlegen, ist halt noch alles in der "Testphase". Es sind ja mehrere Charakterklassen und somit mehrere Tabellen. Dann müsste ich diese Daten nur nach den Klassen filtern (wie z.B. hier).

[BeTwo]

Du setzt einfach eine weitere Spalte dazu, welches die Klasse der Waffe angibt.
z.B. als ENUM

[DMW007]

Das hat mit überlegen und testen nichts zutun, du hast einfach keine vernünftige Datenbankstruktur. Das ist die Grundlage für jedes Projekt und wenn man da anfängt zu murksen passiert das was hier passiert ist, nämlich dass man alles grade noch mal machen kann.
Du hast die dritte Normalform verletzt. Man erstellt in so einem Fall keine 99 Tabellen mit redundanten und inkonsistenten Daten, sondern eine Extra-Tabelle die über einen Fremdschlüssel mit der Waffen-Tabelle verknüpft wird.
Vermute ich zumindestens mal, du geizt hier ja an allen Ecken mit Infos und hast immer noch keine vernünftigen Daten zur Tabellenstruktur gepostet. Außer ein paar Werten ohne Columns, wo man nur raten kann was das für Nummern sein sollen...

[freulein]

Was ich nicht verstehe... wenn in den Tabellen Daten zu Waffen enthalten sind, was hat das mit Charakterklassen zu tun?

Wenn es darum geht, daß bestimmte Charakterklassen nur bestimmte Waffen benutzen können, dann ist es nicht sinnvoll, pro Charakterklasse eine Waffentabelle anzulegen... dann würden ja Waffen mehrfach in verschiedenen Tabellen auftauchen, wenn mehrere Charakterklassen sie verwenden können. Das meint DMW007 damit, daß die dritte Normalform verletzt wird. Wieso soll man die Tatsache, daß eine Waffe Durchschlagskraft 35 hat, in Tabelle A UND Tabelle B UND Tabelle C abspeichern, nur weil die Charakterklassen A, B und C sie verwenden können. Dies birgt neben der Redundanz außerdem das Problem, daß inkonsistente Daten entstehen können. Etwa indem man in Tabelle A die Durchschlagskraft der Waffe auf 36 erhöht, weil sie eigentlich so hoch ist, es aber bei Tabellen B und C vergisst. Dann hat ein- und dieselbe die Waffe in der Datenbank zwei verschiedene Werte zur Durchschlagskraft.

Wie auch schon BeTwo und DMW007 andeuteten, wäre eine vernünftiges Design etwa folgendes:

Tabelle Waffen:
==========

Feld1: Name der Waffe
Feld2 bis n: Daten der Waffe

Tabelle Charakterklassen
================
Feld1: Name der Charakterklasse
Feld2 bis n: Daten der Charakterklasse

Tabelle Waffenverwendung
=================
Feld1: Name der Waffe
Feld2: Name der Charakterklasse

Wenn man dann die Waffen herausfinden will, die eine bestimmte Charakterklasse verwenden kann, setzt man folgendes SQL ab:

Select Feld1 from Waffenverwendung where Feld2 = "Charakterklasse, um die es geht";

oder, wenn man gleich schon alle Waffendaten wissen will:

Select * from Waffen, Waffenverwendung where Waffen.Feld1 = Waffenverwendung.Feld1 and Waffenverwendung.Feld2 = "Charakterklasse, um die es geht";

[BeTwo]

SELECT * FROM Waffen WHERE EXISTS(SELECT * FROM Waffenverwendung WHERE Waffen.name = Waffenverwendung.name AND Waffenverwendung.klassenname = 'Engineer')

wäre der Sinniger Query. Zumindest von der Denkweise her.

[John Gotti]

Subquerys sind teilweise ineffizienter (suboptimal halt, sagt ja schon der Name ).
Ich würde daher Joins bevorzugen. Schwerer oder unlogischer sind sie auch nicht, wenn man verstanden hat wie sie funktionieren. Das sind aber eh Grundlagen, die man als Entwickler der mit SQL zutun hat können sollte. Natürlich hängt es von der Effizienz des DMBS ab. Subquerys werden heute besser erkannt und z.B. vom Mysql-Parser teils ähnlich performant wie Joins abgearbeitet. Dann gibt es auch noch den Fall wo Subquery und Join gleichauf liegen.
Wenn man Subquerys benutzt sollte man aber vorsichtig sein. Besonders wenn man etwas in die Datenbank schreibt. Da kann man sich sonst böse Fallstricken basteln die z.B. zu unnötig langen Tabellensperren führen können.

[BeTwo]

John Gotti wie du richtig gesagt hast, sind die Zeiten vorbei, wo die so unperformant sind. Gerade wenn man die Indexes richtig setzt sind die nahezu gleich schnell wie ein Join, in manchen Fällen sogar schneller.

Das Join schwerer oder unlogischer ist, habe ich nie behauptet. Ich bevorzuge Joins - aber hier musst du von einem Noob in SQL ausgehen. Und daist die Subquery Variante einfacher nachvollziehen, da sie näher an unserer Sprache liegt.

Hole alle Daten von Waffen, die Klasse XYZ benutzen kann.