Eckige Klammern im Feldnamen

[Shadun]

Also, ich hab folgendes Problem. Ich benutze MySql.
Ich will eine Tabelle erstellen, die in einem der Feldnamen eine eckige Klammer benutzt. Das sieht so aus:

CREATE TABLE user (
ID INT NOT NULL auto_increment,
PRIMARY KEY (ID),
feld[2] VARCHAR(20) NOT NULL
);

Nun weiß ich schon, dass die eckige Klammer reserviert ist, aber ich weiß auch, dass es irgendwie gehen muss, weil phpMyAdmin kein Problem mit dem Anlegen dieser Tabelle hat.
Nur will ich das dynamisch machen. Ich hab schon versucht, wie in MS-SQL die eckigen Klammern selbst in eckige Klammern setzen, oder sie mit einfachen oder doppelten Anführungsstrichen valid zu machen, aber nichts funktioniert, und google liefert mir darauf keine sinnvolle Antwort

[onemorenerd]

Wozu denn bitte?

[Shadun]

In der eckigen Klammer die Zahl ist ein Index auf eine ID in einer anderen Tabelle.
Das bietet sich am besten an, mit FOREIGN erziehle ich hier nicht den selben Effekt.

[goth]

Original geschrieben von onemorenerd
Wozu denn bitte?

Weil diese hohle Idee hier bisher keiner hatte ... !

OffTopic:

---

Ja Leute, tut euch keinen Zwang an, wir sind immernoch auf der Suche nach der dümmsten Idee aller Zeiten ... vorschläge bitte unter duemmste_idee_aller_zeiten[at]php-ressource.de

---

[phoenix20]

`feld[2]`

`heisst backtick

[Shadun]

Ok, danke für die Hilfe.

Btw, hatte ganz vergessen wie lustig "Moderatoren" sein können

[onemorenerd]

Wenn ein Attributname die ID eines Tupels einer anderen Relation enthält, machst du was verkehrt.

Zumindest fällt mir kein Szenario ein, das soetwas erfordern würde und ich sehe auch nicht, dass es irgendwie "praktisch dynamisch" ist.

[ghostgambler]

Original geschrieben von onemorenerd
Wenn ein Attributname die ID eines Tupels einer anderen Relation enthält, machst du was verkehrt.

Zumindest fällt mir kein Szenario ein, das soetwas erfordern würde und ich sehe auch nicht, dass es irgendwie "praktisch dynamisch" ist.

sehe ich exakt genauso

[phoenix20]

Original geschrieben von ghostgambler
sehe ich exakt genauso

`Der gewundene Weg ist weniger steil.`

[goth]

Original geschrieben von phoenix20
`Der gewundene Weg ist weniger steil.`

Na ... das ist doch mal ein Attribut name ... sogar in Backtick's ... !

Anyway ... ändert nix ... das ganze hier ist ein Trollthema ... !

@Shadun: Keine Sorge ... ich werde nie vergessen wie trollig User sind ... !

[Shadun]

Der wahre Künstler stellt sich die Frage gar nicht, ob sein Werk verstanden werden wird oder nicht.

-- Adalbert Stifter

@goth:

Die verstehen sehr wenig, die nur das verstehen, was sich erklären lässt.

--Marie von Ebner-Eschenbach

und noch eins:

Kritisiere nicht, was du nicht verstehen kannst.

--Bob Dylan

7 Beiträge, und nur einer, der auf die Frage antwortet. Weiter so ... eure Meinung ist gefragt. Wir leben ja schließlich in einer Demokratie. Da darf jeder zu jedem eine Meinung haben, auch wenn es zu dem Thema eigentlich keine Meinung geben kann. . .

[wahsaga]

Gut, wenn du deine Idee hier so hartnäckig verteidigst - wärst du dann so nett, die folgende Aussage mal etwas genauer zu erläutern?
Würde mich wirklich interessieren, wozu man so etwas brauchen sollte.

In der eckigen Klammer die Zahl ist ein Index auf eine ID in einer anderen Tabelle.
Das bietet sich am besten an, mit FOREIGN erziehle ich hier nicht den selben Effekt.

[Shadun]

Klar, gerne.
Folgendes macht das Script:
Es liest die Beschreibung der Tabelle aus, geht Field für Field durch und erstellt daraus das Input-Formular und das Script zum Verarbeiten. Nicht jedes Feld hat eine eckige Klammer, nur die, die mit einer anderen Tabelle 'verlinkt' sind. Beispiel wäre, wenn man den User auffordert, seinen Benutzernamen, Passwort und, banal aber als Beispiel ausreichend, sein Sternzeichen aus einem DropDown auszuwählen. Das Script muss dann irgendwie wissen, dass es die Sternzeichen aus einer anderen Tabelle und da aus einem speziellen Feldnamen auslesen muss. Das heißt, der Feldnamen würde ca. so aussehen:

zeichen[sternzeichen|name]

Damit weiß das Script, wie es das Input-Formular erstellen muss.

So, jetzt will ich die hören die Meta-Informationen als Datensatz speichern, nur zu...

[onemorenerd]

Du versiehst die Datenbankstruktur mit einer Semantik, die außerdem eine Logik in der Applikation braucht, um die Darstellung zu beeinflussen. Mit Verlaub, das ist idiotisch. Oder anders ausgedrückt: Jeder Fremde wird deinen Code belächeln und wenn du noch an anderen Stellen so denkst und programmierst, wirst du ihn selbst schon nächstes Jahr nicht mehr verstehen.

Mal ehrlich, was gewinnst du denn mit deiner Umsetzung, was du nicht auch in der Applikation erledigen könntest?

Auf jeden Fall verlierst du etwas: Flexibilität.
Wenn du schon Foreign-Key-Beziehungen nachbaust, dann leg dir dafür eine eigene Tabelle an oder baue die Beziehung direkt im Code ein.

[wahsaga]

Zitat von dir weiter oben:

Das bietet sich am besten an, mit FOREIGN erziehle ich hier nicht den selben Effekt.

Nun, du musst derzeit die Information ja auch irgendwie wieder rausfriemeln.

Ich nehme mal an, das machst du nicht ganz stumpf mit einem SELECT *, und "dann schauen wir in der Applikation mal, unter welchen Spaltennamen dabei die Werte geliefert werden", und besorgst dir die Information dann daraus?

Wenn das halbwegs ordentlich aufgebaut ist, bist du ja sicher den Weg über DESCRIBE gegangen. Dabei sollte es aber m.E. fast ebenso trivial sein, mögliche Foreign Keys auszulesen, wie die Spaltennamen ...