(MySQL) Primary Keys einer Tabelle auslesen++

[Philipp Hasenfratz]

Halihallo Forumer

Ich hätte gerne die Felder des PRIMARYKEY's ausgegeben. Die einzige Möglichkeit, die ich
dazu kenne ist über ein DESCRIBE table_name und dann über das Feld 'key' zu dieser
Information zu gelangen. Meine Frage: gibt es eine andere Möglichkeit über
"hard-core-SQL"? - Was ich mir wünschen würde, wäre etwas in der Form: SHOW PRIMARY_KEY
table_name; sodass ich die Felder auf ein Schlag auslesen könnte.

2. Frage: Kennt jemand ein Perl-Modul, welches Datenbank, Tabellen und Entities
(Datensätze) objektorientiert abbildet (wie M$'s ADO z. B.)? - Wäre soetwas überhaupt
Sinnvoll im Kontext von Webapplikationen[1] (Stichwörter: Performance, Code
Reuseability, komplett und schönes OOP, Schnelligkeit in programmiertechnischer
Umsetzung, 0815-Programmierer-Hilfe, Coderedundanz, UML)?

Meine Frage also: Gibt es eine andere Möglichkeit, als die erstgenannte? - Ich habe in
der Doku noch nicht's derartiges gefunden, möchte dies jedoch verifiziert haben.
Wie steht ihr zu objekt orientierten Schnittstellen zur Datenbank (alla ADO)?

[1] ein Beispiel zur Verwendung wäre dies:
my $neuer_user = $user_table_handler->insert( %daten_des_neuen_users )
$user_table_handler->remove( $neuer_user )

Viele Grüsse

Philipp

PS: Falls ich etwas ungenau beschrieben/erklärt habe, fragt nach und ignoriert nicht
einfach (das ist kein Vorurteil!); wäre (wirklich|natürlich) dankbar für Antworten.

[Alexander Foken]

Moin Moin !

[Meta-Infos wie Primary keys]

Soweit ich weiß nicht. Und um die Sache noch übler zu machen, macht jedes DBMS die Geschichte mit den Meta-Informationen etwas anders.

2. Frage: Kennt jemand ein Perl-Modul, welches Datenbank, Tabellen und Entities
   (Datensätze) objektorientiert abbildet (wie M$'s ADO z. B.)? -

Vielleicht DBIx ? Keine Ahnung.

Wäre soetwas überhaupt
Sinnvoll im Kontext von Webapplikationen[1] (Stichwörter: Performance, Code
Reuseability, komplett und schönes OOP, Schnelligkeit in programmiertechnischer
Umsetzung, 0815-Programmierer-Hilfe, Coderedundanz, UML)?

OOP mag schön zu lesen und (evtl. auch) zu warten sein, aber wenn Du Layer über Layer stapelst, wird die Geschichte zwangsläufig langsamer.  Siehe z.B. http://www.fefe.de/dietlibc/diet.pdf, Seite 7.

Alexander

[Thomas Schmieder]

Hallo Philip,

hast Du es schon mal mit "show index from ..." versucht?

Liebe Grüße aus http://www.braunschweig.de

Tom

[Andreas Korthaus]

Hallo Philipp!

Ich hätte gerne die Felder des PRIMARYKEY's ausgegeben. Die einzige Möglichkeit, die ich
dazu kenne ist über ein DESCRIBE table_name und dann über das Feld 'key' zu dieser
Information zu gelangen. Meine Frage: gibt es eine andere Möglichkeit über
"hard-core-SQL"? - Was ich mir wünschen würde, wäre etwas in der Form: SHOW PRIMARY_KEY
table_name; sodass ich die Felder auf ein Schlag auslesen könnte.

Ich kann jetzt nur für MySQL sprechen, inwieweit das jetz Standard ist weiß ich nicht, aber da gibt es:

SHOW KEYS FROM tabelle [FROM datenbank]

Das Ergebnis guckst Du Dir am besten mit einem var-dump an und Dein problem sollte gelöst sein.

Viele Grüße
Andreas

[Philipp Hasenfratz]

Halihallo zusammen

[...]
Vielen Dank für eure Antworten. Ich hatte gestern leider keine Möglichkeit mehr darauf
zu Antworten, da mir kurz nach dem Posting das ADSL-Modem entrissen wurde (und zu
Hause hab ich kein Internet, aus gutem Grunde) ;-(

Andreas und Thomas: SHOW KEYS|INDEX FROM ist eine gute Lösung. Ich glaube, dass diese
schon mehr taugen, als die DESCRIBE table, da nicht mehr alle Felder ausgelesen werden
müssen und demnach eine Verbesserung der Performance darstellt.

Alexander: Ja, leider ist das ganze nicht "standardisiert". Das macht es unmöglich, eine
allgemeine Lösung zu erstellen. Man müsste für jede DB (falls derartige
Metainformationen überhaupt auslesbar sind) einen eigenen "Layer" schreiben.
DBIx ist zwar objektorientiert, aber es unterscheidet nicht zwischen Datenbank, Tabelle
und Datensatz, was ich mir wünschen würde. Dein Kriterium wegen Performance (bei
Generalisierungen/Spezialisierungen) ist mir leider bewusst.

Mir schwebt da ein Layer
im Kopf herum, der eine Schnittstelle zwischen Objekten der realen Welt (meinetwegen
Kunden, Rechnung, GekaufteArtikel) und der Datenbankrepräsentation derselben, bildet.
Der erste Schritt hierzu ist ein Datenbankabstraktionslayer, der zwischen Datenbank
(dem "Universum" der Anwendung), den darin enthaltenen Tabellen (Objekte/Klassen) und
deren Tupel/Datensätze (Instanzen von Objekten, z. B. eine bestimmte Rechnung xx des
Kunden yy) und den einzelnen "Objekt-Klassen" (eg. Klasse :KundenRechnung) eine
Schnittstelle erstellt. Die Klassen könnten dann von der entsprechenden Tabelleninstanz
erben, eine Instanz der Klasse von der korrespondierenden Datensatz-Instanz.
Das Kriterium Performance ist wirklich etwas schwierig. Natürlich taugt dieses Vorhaben
nicht für sehr oft schreibende/lesende Zugriffe. Ich glaube aber, dass es vertretbar
wäre, dieses Interface für z. B. Kundendaten zu gebrauchen (worauf eigentlich nur der
Kunde selber und der Administrator zugreift => die Frequenz ist niedrig).

zur gestellten Frage: Alexander hat das Stichwort Performance aufgegriffen, wo ich
mit ihm einverstanden bin, dass die Wrapper die natürlichen Feinde der Performance sind.
Gibt's noch Kommentare/Anregungen/(positive) Kritik zu den anderen Stichwörtern?
 - Performance
 - Code Reuseability
 - komplett und schönes OOP
 - Schnelligkeit in programmiertechnischer Umsetzung
 - 0815-Programmierer-Hilfe
 - Coderedundanz
 - UML

oder sind diese im allgemein gehaltenen, noch unspezifizierten Zustand/Beschreibung
nicht beantwortbar?

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo zusammen

ich halte es für Notwendig den Threadtitel zu ändern, sodass vielleicht noch andere
auf den Thread aufmerksam werden. Der Titel "Primary Keys auslesen" zielt auf eine
Wissensfrage und ist demnach schnell beantwortet, so denken vielleicht einige, dass der
Thread bereits beendet ist. Dem ist nicht so, denn...

Das auslesen der Primary Keys war nur eine kleine Frage. Was mich viel mehr interessiert
ist das Prinzip und ob dieses Verwendung findet.

Nehmen wir als Beispiel eine normale Webapplikation. Die Webapplikation stellt dem Kunden
verschiedene Schnittstellen zur Verfügung, um mit der Webapplikation zu interagieren.
Diese Schnittstellen werden meist in eigenständige Programme aufgesplittet und oftmals
"hard-gecoded". Z. B. "neuer Account erstellen", ist ein einfaches INSERT-Statement
zuzüglich E-Mail Versand und anderer Aktivitäten. Ändern sich die Daten des Accounts,
muss auch das Insert-Statement überarbeitet werden, dies hat ggf. Konsequenzen auf andere
Programme, wo die Veränderung auch implementiert werden muss. Durch dieses
Mehrfachgebrauchen der Accountdaten entsteht eine Coderedundanz, die ich verhindern
möchte. Eine einfache Methode dies zu erreichen ist, eine Klasse für den Account zu
erstellen, worauf in jedem Programm zugegriffen wird. Da es meistens mehrere Objekte zu
verwalten gibt (Account, User, Gekaufte Artikel, Artikelportfolio, Warenkorb, ...) ist
auch hier wieder eine Redundanz im Code vorhanden, nämlich, dass jede Klasse direkt mit
der Datenbank interagiert und die SQL Statements direkt in die Klasse eingebunden sind.
Dies kann man verhindern, indem man eine "Datenbank-Abstraktions-Layer" erstellt, welcher
diese INSERT, UPDATE, DELETE und einfache SELECT Statements als genau spezifizierte
Methoden zur Verfügung stellt und ggf. Integrität, Validität und Fehlerfreiheit
sicherstellt. Besonders bei komplexen und vielschichtigen Webapplikationen kann dies
auch eine Vereinfachung darstellen, da jedes Objekt nur von einer entsprechenden
Datensatzinstanz erben muss und man sich vollständig auf die "Verarbeitungs-Methoden"
konzentrieren kann (nicht mehr dieses lästige einfügen, löschen und auslesen von
Objekten); auch ein zentral organisiertes Error-Handling und Logging könnte ggf. von
Nutzen sein.

Deswegen komme ich erst auf den Datenbank-Layer... Und nun meine eigentliche Frage:
Ist das Sinnvoll [1]?

[1] (Mögliche Bewertungs-/Meinungskriterien kann man aus [pref:t=34949&m=190754]
entnehmen)?

Viele Grüsse

Philipp