Aliase für mysql-Feldnamen in DB möglich?

[Linuchs]

Moin,

ein lfd. Projekt ist konzeptionell zu ändern. Dazu gehört auch, dass z.B. die Tabelle "adressen" zu "registrierte" wird, weil dort nur registrierte Teilnehmer enthalten sind.

Logisch, dass auf Feld-Ebene in neuen PHP-Programmen die alte "adress_id" nun mit "registrierte_id" angesprochen werden soll.

Es wäre toll, wenn ich aber deswegen nicht alle alten Programme anfassen muss, sondern in der MySQL-Tabelle alias-Namen vergeben könnte. Also ich spreche adress_id an, geliefert wird aber registrierte_id. Ist das möglich?

Linuchs

[Linuchs]

Bei der Recherche stoße ich gerade auf Views. Welchen Vorteil haben die gegenüber gleichartigen SQL-Kommandos im PHP-Programm?

Gut - man könnte sie von beliebig vielen Programmen aufrufen und nur einmal zentral pflegen. Sonst noch Vorteile, etwa schneller?

(Views hatte ich im letzten Jahrtausend schon bei Oracle, da war MySQL noch nicht so weit.)

Linuchs

[dedlfix]

Tach!

Bei der Recherche stoße ich gerade auf Views. Welchen Vorteil haben die gegenüber gleichartigen SQL-Kommandos im PHP-Programm?

Mit Views kann man komplexere Abfragen hinter einer einfacheren Oberfläche verstecken. Man kann sie auch als vordefinierte Query ansehen.

Gut - man könnte sie von beliebig vielen Programmen aufrufen und nur einmal zentral pflegen. Sonst noch Vorteile, etwa schneller?

Nein, sie sind nicht grundsätzlich schneller. Eine View ist quasi nur ein Alias für eine normale Query. Die Abarbeitung und damit die Beschaffung der Ergebnismenge wird dadurch nicht beeinflusst. Sie sind keine vorausgeführten Statements mit Ergebnis-Cache. (Ein Query-Cache ist in MySQL vorhanden, aber der arbeitet unabhängig von Views.)

Man kann außerdem eine View so definieren, dass der Abfrager Zugriff auf Daten bekommt, den er bei direkter Abfrage der in der View verwendeten Tabelle(n) nicht hat.

dedlfix.

[Der Martin]

Hallo,

ein lfd. Projekt ist konzeptionell zu ändern. Dazu gehört auch, dass z.B. die Tabelle "adressen" zu "registrierte" wird, weil dort nur registrierte Teilnehmer enthalten sind.

Logisch, dass auf Feld-Ebene in neuen PHP-Programmen die alte "adress_id" nun mit "registrierte_id" angesprochen werden soll.

nein, finde ich gar nicht logisch. So wie du es darstellst, ändert sich nur der Tabellenname, das wäre vermutlich eine Zeile im Script. Warum sollten sich auch die Feldnamen noch ändern?

Es wäre toll, wenn ich aber deswegen nicht alle alten Programme anfassen muss, sondern in der MySQL-Tabelle alias-Namen vergeben könnte. Also ich spreche adress_id an, geliefert wird aber registrierte_id. Ist das möglich?

Meines Wissens nicht. Innerhalb eines SQL-Statements können Aliase vergeben werden, aber nicht als fest hinterlegte Tabellen- oder Feldeigenschaften.

So long,
 Martin

[Linuchs]

Moin,

Logisch, dass auf Feld-Ebene in neuen PHP-Programmen die alte "adress_id" nun mit "registrierte_id" angesprochen werden soll.

nein, finde ich gar nicht logisch. So wie du es darstellst, ändert sich nur der Tabellenname, das wäre vermutlich eine Zeile im Script. Warum sollten sich auch die Feldnamen noch ändern?

In vielen anderen Tabellen, z.B. Medien (Hörproben) sind die "registrierten" ja noch mit "adress_id" eingetragen. Es gibt ungezählt viele Zeilen in PHP-Programmen wie

SELECT
...
WHERE  medien.adress_id = adress.id
...

In der Tabelle medien muss das Feld "adress_id" aber in "registrierte_id" geändert werden. Wenn ich das ohne Alias mache, funktionieren die SELECTS nicht mehr.

Welchen Ausweg gibt es? Datenbanken sind so wunderbar variabel, aber hier beisst man auf Granit?

Wenn ich nun das Feld "registrierte_id_neu" hinzufügen würde, könnte ich dann wenigstens auf eine Automatik der Datenbank vertrauen, die jede Änderung im (veralteten, aber noch vorhandenen) Feld adress_id auch in registrierte_id_neu hineinschreibt?

Dieses Anliegen ist doch gar nicht abartig, auch in der PHP-Dokumentation werden bestimmte Kommandos als "veraltet" bezeichnet mit dem Hinweis, andere zu nehmen. Aber die alten gelten noch eine Weile ...

Meines Wissens nicht. Innerhalb eines SQL-Statements können Aliase vergeben werden, ...

Ist mir bekannt und nutze ich auch.

Linuchs

[dedlfix]

Tach!

In der Tabelle medien muss das Feld "adress_id" aber in "registrierte_id" geändert werden. Wenn ich das ohne Alias mache, funktionieren die SELECTS nicht mehr.

Die Reihenfolge der Klausel-Abarbeitung ist wichtig für das WWissen, wann man Aliase einsetzen kann. Diese Reihenfolge entspricht im Wesentlichen der Reihenfolge, wie die Klausel notiert werden müssen. Die Auswertung der SELECT-Klausel kommt aber erst zwischen GROUP BY und HAVING an die Reihe. Das heißt, vorher kann man keine Aliase verwenden, nachher schon. Also WHERE kann nicht mit den Aliasen im SELECT umgehen, aber HAVING und ORDER BY können das. Es ist nun allerdings nicht empfehlenswert, alles WHERE auf HAVING umzuschreiben. WHERE ist dafür da, die Datenmenge einzuschränken, die dann im SELECT-Teil berechnet werden muss. Lässt man erst die Ausdrücke im SELECT berechnen, macht das MySQL unter Umständen (wenn es der Optimizer nicht besser geregelt bekommt) für die gesamte Tabelle. Das will man nicht, besonders nicht dann, wenn das WHERE eine Menge Datensätzt weggekürzt hätte.

Welchen Ausweg gibt es? Datenbanken sind so wunderbar variabel, aber hier beisst man auf Granit?

Die Aliase im SELECT-Teil nur dafür verwenden, wie die Namen später im abfragenden Programm aussehen sollen und die WHERE-Klausel mit den alten Namen belassen oder auf umbenannte Feldnamen anpassen.

dedlfix.

[Google weiß alles]

[Vorab: Alle Befehle sind für die Shell. Windows-Benutzer müssen sich was einfallen lassen.]

Ist das möglich?

Ja.

ABER:

Die dafür nötigen Krücken sind derartig aufwendig und beinhalten so viele Quellen für künftige logische Fehler (z.B. den alten Name weiter benutzt statt den neuen Alias...), dass jedes mögliche Vorgehen nicht wirklich vielversprechend ist. Anders gesagt: Du bist auf dem Weg Dich selbst zu verwirren.

Klar kannst Du eine View a la select foo as bar from tok einrichten und diese befragen. Ein klarer Favorit für eine View wäre aber aus meiner Sicht etwas wie ein Join welchen ich häufig brauche aber eben nicht dauernd neu in den Abfragen notieren will.

Der einfachste und wohl vorteilhafteste Weg:

grep -R 'alter Tabellenname' > /tmp/bearbeiten.txt

in /tmp/bearbeiten.txt steht dann brav jedes Vorkommen von 'alter Tabellenname' mit Dateiname und Zeilennummer aus allen Dateien im aktuellen Verzeichnis und darunter. Dazu auch die komplette Zeile. Man kann schön sehen, was man zu tun hat und am Ende oder zwischendurch das einfach nochmal machen. Als Fortschritts oder Qualitätskontrolle. Datei mit vi aufrufen, +[Zeilenummer -1] eintippen und Du bist dort, wo Du hinwillst. Alternativ kannst Du daraus auch ein File für patch bauen.

Man kann, mit der Gefahr der unerwünschten Ersetzung, auch sed -i verwenden:

sed -i "s/FOO/BAR/g"  datei.php

Damit kann man aber auch sehr hübsch den Dateiinhalt zerstören: z.B. wenn irgendein Vorkommen von FOO nicht ersetzt werden soll.

Hat man jetzt viele Dateien in einem Ordner, dann kann man das mit einem Einzeiler erledigen:

find ./ "*.php" -print0 | xargs -0 sed -i "s/FOO/BAR/g"

Findet jede PHP-Datei im und unterhalb des aktuellen Verzeichnisses und schickt für jeden Fund sed los um diese zu verändern. Das -print0 und xargs -0 sorgt übrigens dafür, dass zwischen den Dateinamen im gelieferten String das in Dateinamen nicht zulässig NULL-Byte als Trenner eingefügt und von xargs dann als Trennzeichen beachtet wird.

ein lfd. Projekt ist konzeptionell zu ändern.

Änderungen am Konzept führen immer zu einem neuen Major-Release. Dabei den scheinbar billigen Weg zu gehen und über irgendwelche Aliase Arbeit sparen zu wollen wird sich später übel rächen.

Anders ausgedrückt: "WER macht denn SOWAS?"

[dedlfix]

Tach!

[Vorab: Alle Befehle sind für die Shell. Windows-Benutzer müssen sich was einfallen lassen.]

Zum Beispiel Notepad++ mit seiner Funktion „Suchen und Ersetzen in Dateien“.

dedlfix.