Thema: Unique Keys in MySQL

[der.hobbit]

Hi,

in einem aktuellen Projekt würde ich gerne auf Objekte in beliebigen Tabellen eindeutig zugreifen können. Simples Beispiel: Ich habe eine ID '17' und möchte mit einer einzigen Anfrage das Objekt Nr. '17' bekommen, unabhängig davon ob es in der Benutzer oder Benutzergruppen oder Bananen-Tabelle sitzt. Setzt natürlich voraus, dass die 17 datenbankweit eindeutig ist.

Weiß jemand, wie man das möglichst effizient löst? DB ist MySQL, Sprache ist PHP.

Danke für Tipps!

[Haukrinn]

Eine weitere Tabelle einführen, die globale ID's mit allen gespeicherten Tabellenzeilen verknüpft (Also drei Spalten GlobalID, TableID, TableEntryID)? Alles andere wäre wohl geschummelt. Aber wozu brauchst Du das überhaupt? Ich rieche da einen dicken Fehler im Anwendungsdesign...

[der.hobbit]

Die Idee hatte ich auch schon, aber sie gefällt mit nicht, weil sich die Anfragen verdoppeln. Zumindest habe ich keine Möglichkeit gefunden, mit einer einzigen SQL-Abfrage das entsprechende Objekt zu einer ID zu holen.

Ich brauche es für Vererbung: Ich habe verschiedene Objekte, sagen wir mal ein Obst-Objekt und ein Bananen-Objekt. Das Banenobjekt erbt von Obst. Nun habe ich eine Seite, die ein Obst-Objekt erwartet, und als Parameter wird die id in der URL übergeben. Es soll aber möglich sein, hier die id sowohl eines Obst-Objekts als auch eines Bananen-Objekts einzugeben.

Wenn die Ids nicht eindeutig sind, dann geht das nicht (jupp, ich könnte auch den Objektnamen mitschicken, aber das fände ich unschöner als global geltende Keys, da diese Kommunikation über den Browser läuft und dementsprechend für den Benutzer sichtbar ist).

[Wawoozle]

Hä ?
Du hast ne Seite die nur die ID übermittelt, nehmen wir mal an 17.
Was machst du denn auf der Serverseite damit ?

[Hr. Rabe]

Die Idee hatte ich auch schon, aber sie gefällt mit nicht, weil sich die Anfragen verdoppeln. Zumindest habe ich keine Möglichkeit gefunden, mit einer einzigen SQL-Abfrage das entsprechende Objekt zu einer ID zu holen.

Ich brauche es für Vererbung: Ich habe verschiedene Objekte, sagen wir mal ein Obst-Objekt und ein Bananen-Objekt. Das Banenobjekt erbt von Obst. Nun habe ich eine Seite, die ein Obst-Objekt erwartet, und als Parameter wird die id in der URL übergeben. Es soll aber möglich sein, hier die id sowohl eines Obst-Objekts als auch eines Bananen-Objekts einzugeben.

Wenn die Ids nicht eindeutig sind, dann geht das nicht (jupp, ich könnte auch den Objektnamen mitschicken, aber das fände ich unschöner als global geltende Keys, da diese Kommunikation über den Browser läuft und dementsprechend für den Benutzer sichtbar ist).

Hä?
Warum zum Geier machst du dann nicht eine Obst-Tabelle, die eine Namens-Spalte enthält (dort steht dann z.B. 'Banane').
Wenn du wirklich noch speziefische Eigenschaften persistieren willst, könntest du das ganze mit einer Obst_Details Tabelle ergänzen. (Obst_Id | Detail_Type | Detail_Value).
Nur ein Vorschlag.

Andererseits kann ich mir wirklich keine vernünftige Anwendung vorstellen, in der man auf eine echte Vererbungshirarchie in Persistenz-Objekten angewiesen wäre.
Ich glaube eher, daß du dir dringend nochmal ein bischen Normalisierung anschauen solltest.

[der.hobbit]

Ich nutze diese ID um mir das entsprechende Objekt aus der DB zu holen. Das ist kein Thema, solange eindeutig klar ist, welches Objekt gemeint ist. Das funktioniert ganz gut, nur eben nicht mehr bei der Vererbung, weil diese Eindeutigkeit dann nicht mehr gegeben ist.

Hmmm, ich glaube, ich muss die Abbildung der Vererbung auf die DB überlegen, und wohl eher hier die entsprechenden Elemente erweitern. Dann muss ich zwar auf der programmatischen Seite für jedes Objekt dessen Vaterhierarchie aufbereiten, um alle notwendigen Tabellen zusammenzujoinen, spare mir aber andererseits auch redundante Spaltendefinitionen....

[der.hobbit]

Ach Kinners, Normalisierung kenne ich...

Es geht tatsächlich darum, dass die Vererbung etwas komplexer ist als "das Obst hat noch den Namen Banane...."

Bei der Referenzierung von der Vater- auf die Kindtabelle habe ich auch wieder das Problem mit der einzelnen Anfrage, das war der Grund, warum ich es initial nicht so gemacht habe.

Nehmen wir an, das Obst hat neben den Obstspalten noch eine für den Verweis auf die Bananen-ID und eine für die entsprechende Tabelle. Wie kann ich mit einer einzigen SQL-Abfrage diese zusammenjoinen? Denn ich weiß ja zuvor nicht, ob ich eine Banane oder einen Apfel in der Hand halte. Oder sogar einen Granny-Smith, das ganze muss ja transitiv funktionieren.... Argh!

[Sir Mythos]

Mein Tipp wäre, pack alles nochmal in EINE Tabelle und mach die Normalisierung dann von Hand.
Mit ner vernünftigen Normalisierung erledigen sich die Abfragen meistens von selbst.

[Hr. Rabe]

Nehmen wir an, das Obst hat neben den Obstspalten noch eine für den Verweis auf die Bananen-ID und eine für die entsprechende Tabelle.

Ebenso wie Hendrik nehme ich aufgrund dieser Ausage eben stark an, daß hier ein Design-Schnitzer vorliegt und du dein Gesamtproblem höchstwahrscheinlich einfacher und besser (= eleganter) lösen kannst.

Poste doch mal dein Ursprungsproblem, vieleicht fällt uns dazu was ein.

[Wawoozle]

Ich sehe gerade deinen Zusammenhang zwischen Vererbung und dem DB Zugriff nicht.

Nehmen wir mal deine Bananen.
Auf Objektseite würde das ja so aussehen:

Du hast 2 Objekte.
Obst und Banane, wobei Banane von Obst erbt.

Auf der DB-Schicht hast Du ja (sofern du keine ODBMS verwendest) eher sowas in der Art:

Tabelle: Obst
PK: id
Col1: farbe
Col2: familie

Tabelle: Banane
PK: id
FK: obst_id -> Obst
Col1: herkunftsland

@normalisierer:
Bitte baut mir jetzt keine Länder, Farben und Familientabellen

[der.hobbit]

Nehmen wir genau Wawoozles Beispiel.

Jetzt kommt eine Anfrage "ZeigeObst" mit der ID 3 als URL herein. Woher weiß ich jetzt, ob der Benutzer die Banane mit PK 3 oder aber das Obst mit PK 3 meint?

[Wawoozle]

Warte mal...
das liest sich jetzt als würdest auf der Client (Web) Seite einen universellen Client haben der eigentlich nur ne Textbox hat in die man eine ID tippt.

Der Server muss dann also mittels Kristallkugel-API herausfinden was er mit dieser ID anstellen soll und genau das ist dein Problem, oder ?

[der.hobbit]

Mehr oder weniger - der User tippt die ID nicht ein, sondern die werden automatisch z.B. als Links generiert. Aber vom Prinzip her, ja. Magischer Wahrsage-Server, sozusagen.

[Wawoozle]

Ok... ich sehe wir nähern uns dem Problem

Hast Du den Client in der Hand oder bist Du nur für den Server zuständig ?

[der.hobbit]

Der Client ist ein Browser, die Seiten werden vom Server generiert. Von daher habe ich freie Hand. Ich könnte also theoretisch auch zusätzliche Infos in die ID reinlegen, das ist mein Notfallplan. Momentan suche ich aber noch nach einer schlankeren Lösung.

[Wawoozle]

Momentan suche ich aber noch nach einer schlankeren Lösung.

Warum ?
Meinst Du für Server und Client macht es einen unterschied ob er eine oder zwei ID's übermittelt ?
Eine ID die den Objekttyp beschreibt und die andere die den Key definiert.

Performance wäre ein Thema wenn Du zwischen 10 und 50 Request/Session Parametern entscheiden müsstest und selbst dann nichtmal notwendigerweise.

[der.hobbit]

Hauptsächlich will ich die schlankere Lösung, weil die Parameter in der URL sichtbar sind. Aber ich sehe schon, die Alternativen sind nicht besonders prickelnd.

[Wawoozle]

Naja... was die Parameter in der URL angeht gibt es unterschiedliche Möglichkeiten, je nachdem welche Tools du im Werkzeugkasten hast.
Womit entwickelst Du denn ?

[der.hobbit]

Ich schraube gerade an einem eigenständigen Framework. Ich habe mir ein paar Frameworks angeschaut (z.B. ez-components), aber war da mit der Performance nicht so ganz zufrieden.

Wahrscheinlich klassisches "not-invented-here" Syndrom 

[Hr. Rabe]

Hauptsächlich will ich die schlankere Lösung, weil die Parameter in der URL sichtbar sind. Aber ich sehe schon, die Alternativen sind nicht besonders prickelnd.

POST statt GET?

[Wawoozle]

POST statt GET?

Hilft nur bedingt wenn die Parameter in form von Links übergeben werden.

@hobbit
Aber eine Alternative ist das natürlich schon.
Mir stellt sich im moment eher die Frage ob Du überhaupt Forms verwendest oder arbeitest Du rein mit Linklisten ?

ez-components, demnach gehts um PHP ?

[Haukrinn]

Jetzt kommt eine Anfrage "ZeigeObst" mit der ID 3 als URL herein. Woher weiß ich jetzt, ob der Benutzer die Banane mit PK 3 oder aber das Obst mit PK 3 meint?

Also willst Du eine Objekthierarchie ohne jegliches O/R-Mapping abbilden und nur direkt auf irgendwelchen ID's arbeiten? Davon würde ich aber abraten. Dann kannst Du nämlich auch gleich "alle" möglichen Informationen in eine einzige Tabelle packen. Wieso verwendest Du nicht einfach konkrete IDs wie die Namen des Obstes und durchsuchst dann die Hierarchie (hey, meistens braucht man ja auch die die Informationen der abgeleiteten Klassen garnicht. Wenn Du sowas partout haben willst, bist Du mit Deinem Vorgehen eh auf dem Holzweg - diesmal aber aus sicht der OOP, nicht der Datenbanken...  . Hast Du so wenig vertrauen in die Performanz Deines DB-Servers?

[der.hobbit]

POST ist vor allem unschön bei Reloads, weil dann ständig Browser-Nachfragen kommen. Außerdem ist es inhaltlich falsch, denn es werden ja keine Daten für den Server übermittelt, sondern Daten vom Server angefragt (in diesem konkreten Beispiel).

Es gibt beide Fälle, sprich Formulare und Links. Ich finde eine Lösung, die in beiden Varianten funktioniert, sollte drin sein.

O/R-Mappings kenne ich mich nicht aus, gibt es da eine gute Zusammenfassung, wie man optimal vorgehen kann?

Alle Informationen in einer Tabelle ist nun doch eine etwas andere Kategorie als das was ich hier fabriziere. Was die Performance der Datenbank angeht - da gehe ich davon aus, dass ich niemals in Probleme komme, da die Seiten auch keinen extremen Traffic produzieren. Aber trotzdem möchte ich keine unnötigen Queries fabrizieren, nenn es Anspruch an die Software.

PHP is korrekt. Was den Anspruch an die Software wieder in einem gewissen Rahmen ad absurdum führt

[Wawoozle]

Fassen wir mal zusammen was wir bisher haben:
- PHP
- mySQL
- wenig Erfahrung was O/R-Mapping angeht
- "keine unnötigen Queries"
- "nicht zuviele Parameter in der URL"

Was mich zu der Frage führt, was hast Du gegen mehrere ID's in der URL ?
Sind das Performancebedenken oder Sicherheitsbedenken ?

[der.hobbit]

Sicherheit sowie Ästhetik (humanreadable URLs). Oi, bei mir brennt gerade in der Realität die Bude, bin wahrscheinlich heute nicht mehr online. Danke schon mal für die Hilfe und Tipps!

[Haukrinn]

Es gibt beide Fälle, sprich Formulare und Links. Ich finde eine Lösung, die in beiden Varianten funktioniert, sollte drin sein.

Hmm, das Ganze AJAX-mässig aufziehen und die schwergewichtigen Informationen in ein XMLQuery-Objekt auslagern?

O/R-Mappings kenne ich mich nicht aus, gibt es da eine gute Zusammenfassung, wie man optimal vorgehen kann?

O/R Mapping 101: http://www.agiledata.org/essays/mappingObjects.html 

Alle Informationen in einer Tabelle ist nun doch eine etwas andere Kategorie als das was ich hier fabriziere.

Du wirst lachen - das ist trotzdem für viele Objekthierarchien die beste Lösung.

Aber trotzdem möchte ich keine unnötigen Queries fabrizieren, nenn es Anspruch an die Software.

Man sollte aber auch nicht weniger Queries machen, als man für eine vernünftige Lösung braucht. Eine saubere Lösung mit 3 Queries würde ich einer unsauberen mit einer Query immer vorziehen.

PHP is korrekt. Was den Anspruch an die Software wieder in einem gewissen Rahmen ad absurdum führt

Ach komm, so unprofessionel ist PHP nicht. Man muss ja nicht gleich für jede Anwendung EJBs und 'nen Application Server benutzen. Und besser als ASP/.NET ist PHP allemal...