MYSQL Spaltenname darf nicht "from" sein?

[davidp]

Hi, ich habe eine Tabelle mit einer Spalte die from heißt. Ich habe lange gebraucht, bis ich herausgefunden habe, dass das Eintragen bei der Spalte scheitert. Der MySql-Befehl FROM ist aber großgeschrieben. Heißt das, die Spalte darf überhaut nicht so heißen? Und bei MySql könnten dann alle Befehle auch kleingeschrieben funktionieren? (select spalte from tabelle where id like 1 ??)

lg davidp

[LX]

MySQL unterscheidet bei Queries nicht zwischen Groß- und Kleinschreibung.

Gruß, LX

[Christoph Jeschke]

Guten Tag,

MySQL unterscheidet bei Queries nicht zwischen Groß- und Kleinschreibung.

Das ist so undifferenziert falsch: Schlüsselwörter und Spaltennamen (und noch ein paar  andere Qualifier) sind nicht case-sensitive. Jedoch gibt es Literale, die case-sensitive sind oder sein können.

Gruß
Christoph Jeschke

[Cheatah]

Hi,

Der MySql-Befehl FROM ist aber großgeschrieben.

SQL ist case-insensitive. "FROM" ist identisch mit "fRoM". Lediglich per Konvention schreibt man idealerweise alle SQL-Kommandos groß.

Heißt das, die Spalte darf überhaut nicht so heißen?

Es ist definitiv besser, einen solchen Namen nicht zu verwenden.

Cheatah

[suit]

Heißt das, die Spalte darf überhaut nicht so heißen?

Es ist definitiv besser, einen solchen Namen nicht zu verwenden.

was aber nicht heisst, dass sie nicht so heissen dürfen - jedes dmbs hat eine entsprechede syntax zum escapen von schlüsselwörtern - mssql zb verwendet eckige klammern

ein feld welches "key" heisst, sollte mit [key] escaped werden

für mysql gibts natürlich auch entsprechendes

[Peter Pan]

Hi!

Heißt das, die Spalte darf überhaut nicht so heißen?

Es ist definitiv besser, einen solchen Namen nicht zu verwenden.

was aber nicht heisst, dass sie nicht so heissen dürfen - jedes dmbs hat eine entsprechede syntax zum escapen von schlüsselwörtern - mssql zb verwendet eckige klammern

Ja, aber eine potentielle Migration wird durch eine solche Benennung erschwert, warum also nicht auf diese verzichten?

off:PP

[dedlfix]

echo $begrüßung;

Ja, aber eine potentielle Migration wird durch eine solche Benennung erschwert, warum also nicht auf diese verzichten?

Das Argument der Migration wird zwar gern genommen, ist aber meist stark überbewertet. In einer Vielzahl der Fälle wird es keine Migration geben. Für den geringen Rest ist immer eine Einzelfallbetrachtung angebracht. Niemand wird ernsthaft auf die Idee kommen, von System X nach System Y umzustellen, ohne eine Anpassungs- und Testphase einzuplanen. Vermutlich wird dann auch kein allgemeines Kriterium wie Geschwindigkeit den Ausschlag geben, sondern vielmehr die Feature-Liste des anderen Systems. Und das bedeutet zweifelsohne einen Umstellungsaufwand, bei dem unter anderem auch die Syntax berücksichtigt und behandelt werden muss.

Speziell in diesem Fall der Benennung ist mir bisher kein DBMS begegnet, das keine Syntax zur eindeutigen Kennzeichnung eines Bezeichner bietet. Eine Benennung unter Berücksichtigung der Schlüsselwörter muss nur dann vermieden werden, wenn man partout keine Identifizierquotierungen einsetzen darf[1]/will[2]/kann[3]. Und dabei muss man theoretisch alle (auch zukünftigen) Schlüsselwörter der beteiligten oder in Frage kommenden DBMS berücksichtigen, wenn man genau sein will.

[1] Schicksal. Gegen blödsinnige Entscheidungen übergeordneter Instanzen kommt man nicht immer an.
[2] Selbst dran schuld. Nicht mein Problem. Und hoffentlich wird es auch nicht meins werden.
[3] Unzulängliche Werkzeuge sind eine Ursache, doch die einzusetzen fällt unter [1] oder [2].

echo "$verabschiedung $name";

[suit]

Und dabei muss man theoretisch alle (auch zukünftigen) Schlüsselwörter der beteiligten oder in Frage kommenden DBMS berücksichtigen, wenn man genau sein will.

das ist natürlich etwas zu viel des guten - aber wenn man zumindest vermeidet, felder nach wirklich verbreiteten schlüsselwörtern zu benennen, spart man sich einiges an arbeit und sucherei (im eigenen interesse)

felder "from", "select", "where", "limit" oder "cast" zu nennen muss ja nicht sein

[dedlfix]

echo $begrüßung;

Und dabei muss man theoretisch alle (auch zukünftigen) Schlüsselwörter der beteiligten oder in Frage kommenden DBMS berücksichtigen, wenn man genau sein will.
das ist natürlich etwas zu viel des guten - aber wenn man zumindest vermeidet, felder nach wirklich verbreiteten schlüsselwörtern zu benennen, spart man sich einiges an arbeit und sucherei (im eigenen interesse)

Möchtest du damit implizit sagen, dass das Problem bei einem weniger verbreiteten Schlüsselwort nicht auftritt, sich weniger gravierend auswirkt, die Vermeidungs- oder Umgehungsmaßnahme eine andere ist oder sonst irgendein Unterschied zu einem häufig benutzten Wort besteht? Wohl kaum. Man spart sich nichts. Es kann im Gegenteil sogar so sein, dass einem das Problem bei einem unbekannten Schlüsselwort sogar noch weniger gut auffällt.

felder "from", "select", "where", "limit" oder "cast" zu nennen muss ja nicht sein

Sie nicht so zu nennen und damit Verrenkungen und im jeweiligen Anwendungskontext weniger gut verständliche Bezeichner zu wählen macht die Sache nicht besser. (Wozu hat man denn die kontextgerechte Behandlung erfunden? :-)

echo "$verabschiedung $name";

[Shadowcrow]

hi $name,

Hi,

Der MySql-Befehl FROM ist aber großgeschrieben.

SQL ist case-insensitive. "FROM" ist identisch mit "fRoM". Lediglich per Konvention schreibt man idealerweise alle SQL-Kommandos groß.

Heißt das, die Spalte darf überhaut nicht so heißen?

Es ist definitiv besser, einen solchen Namen nicht zu verwenden.

im PHH TUT steht was ganz anderes..??????

gruss
shadow

[Christoph Jeschke]

Guten Tag,

Heißt das, die Spalte darf überhaut nicht so heißen?

From ist ein case-insensitives Schlüsselwort in MySQL. Du kannst Schlüsselwörter als Spaltenname verwenden, in dem du sie mit den entsprechenden Quotes umschließt. In diesem Falle:  from - die Art der Quotezeichen ist dabei maßgeblich.
Spaltennamen sind übrigens auch case-insenstive: Die Spaltennamen foo, f00 und FoO sind äquivalent.

Reserved Keywords in MySQL 5.0
Schema Object Names
Identifier Case Sensitivity

Gruß
Christoph Jeschke

[Timo "God's Boss" Reitz]

Spaltennamen sind übrigens auch case-insenstive: Die Spaltennamen foo, f00 und FoO sind äquivalent.

Moment mal, glaubst du wirklich, du kommst damit davon? Oder werden in l33t geschrieben Buchstaben automatisch konvertiert?

[Christoph Jeschke]

Guten Tag,

Moment mal, glaubst du wirklich, du kommst damit davon? Oder werden in l33t
geschrieben Buchstaben automatisch konvertiert?

;-)

Gruß
Christoph Jeschke

[Ilja]

yo,

Spaltennamen sind übrigens auch case-insenstive: Die Spaltennamen foo, f00 und FoO sind äquivalent.

wäre ich vorsichtig damit, besonders wenn man einen qualifier benutzt. bei oracle zum beispiel gibt es keine case-sensitive funktionalität, auch wenn es auf ersten ersten blick so aussieht.

Ilja

[Christoph Jeschke]

Guten Tag,

yo,

Bitte?

wäre ich vorsichtig damit, besonders wenn man einen qualifier benutzt. bei oracle
zum beispiel gibt es keine case-sensitive funktionalität, auch wenn es auf ersten
ersten blick so aussieht.

Es geht allerdings um MySQL und nicht um Oracle. In MySQL sind Spaltennamen immer case-insenstive, egal ob man sie quotet oder nicht.

Gruß
Christoph Jeschke

[Ilja]

yo,

Es geht allerdings um MySQL und nicht um Oracle. In MySQL sind Spaltennamen immer case-insenstive, egal ob man sie quotet oder nicht.

ich habe leider keine mysql datenbank hier und wie gesagt, es ist eine vermutung. aber ob quoted spalten-namen wirklich nicht case-sensitive sind, würde ich glatt mal ausprobieren.

Ilja

[Christoph Jeschke]

Guten Tag,

ich habe leider keine mysql datenbank hier und wie gesagt, es ist eine
vermutung. aber ob quoted spalten-namen wirklich nicht case-sensitive sind,
würde ich glatt mal ausprobieren.

Doch, da bin ich mir ganz sicher:

> describe City;  

+-------------+----------+------+-----+---------+----------------+  
| Field       | Type     | Null | Key | Default | Extra          |  
+-------------+----------+------+-----+---------+----------------+  
| ID          | int(11)  | NO   | PRI | NULL    | auto_increment |  
| Name        | char(35) | NO   |     |         |                |  
| CountryCode | char(3)  | NO   |     |         |                |  
| District    | char(20) | NO   |     |         |                |  
| Population  | int(11)  | NO   |     | 0       |                |  
+-------------+----------+------+-----+---------+----------------+  
5 rows in set (0,00 sec)

> SELECT `ID`,`NAmE`,cOUNtRYcODe FROM City LIMIT 1;  

+----+-------+-------------+  
| ID | NAmE  | cOUNtRYcODe |  
+----+-------+-------------+  
|  1 | Kabul | AFG         |  
+----+-------+-------------+  
1 row in set (0,00 sec)  
  

> SELECT `ID`,`Name`,CoUNtrYCoDE FROM City WHERE cOUntryCODe = 'AFG';  

+----+----------------+-------------+  
| ID | Name           | CoUNtrYCoDE |  
+----+----------------+-------------+  
|  1 | Kabul          | AFG         |  
|  2 | Qandahar       | AFG         |  
|  3 | Herat          | AFG         |  
|  4 | Mazar-e-Sharif | AFG         |  
+----+----------------+-------------+

Das ist nicht sehr hübsch, funktioniert aber.

Gruß
Christoph Jeschke

[Ilja]

yo,

scheint zu gehen, wobei mich vielmehr interessiert hätte, wie die tabelle angelegt wurde.

Ilja

[Christoph Jeschke]

Guten Tag,

scheint zu gehen, wobei mich vielmehr interessiert hätte, wie die tabelle angelegt
wurde.

Diese Information findest du im Output von DESCRIBE, im ersten Block.

Gruß
Christoph Jeschke

[Ilja]

yo,

Diese Information findest du im Output von DESCRIBE, im ersten Block.

den befehl dazu, das it der relevante teil.

Ilja

[Christoph Jeschke]

Guten Tag,

den befehl dazu, das it der relevante teil.

SHOW CREATE TABLE City\G  
*************************** 1. row ***************************  
       Table: City  
Create Table: CREATE TABLE `City` (  
  `ID` int(11) NOT NULL auto_increment,  
  `Name` char(35) NOT NULL default '',  
  `CountryCode` char(3) NOT NULL default '',  
  `District` char(20) NOT NULL default '',  
  `Population` int(11) NOT NULL default '0',  
  PRIMARY KEY  (`ID`)  
) ENGINE=MyISAM AUTO_INCREMENT=4080 DEFAULT CHARSET=latin1  

Nichts anderes steht im Output von DESCRIBE.

Gruß
Christoph Jeschke

[Ilja]

yo,

Nichts anderes steht im Output von DESCRIBE.

ich bin bei mysql meistens auf vermutungen angewiesen, sollte mir mal wieder das dbms installieren, um dinge selbst auszuprobieren. aber ich dachte eher bei der erstellung an einfachen oder doppelten anführungszeichen beim qualifier der spaltennamen.

Ilja

[Christoph Jeschke]

Guten Tag,

aber ich dachte eher bei der erstellung an einfachen oder doppelten
anführungszeichen beim qualifier der spaltennamen.

Die sind bei MySQL dort eh nicht erlaubt und hätten keinen Einfluss auf die case sensitivity der Spaltennamen.

Gruß
Christoph Jeschke

[hotti]

Hi,

Hi, ich habe eine Tabelle mit einer Spalte die from heißt. Ich habe lange gebraucht, bis ich herausgefunden habe, dass das Eintragen bei der Spalte scheitert. Der MySql-Befehl FROM ist aber großgeschrieben. Heißt das, die Spalte darf überhaut nicht so heißen?

MySQL ist da wirklich dof manschmal. Aber selbst wenn ich MySQL wäre, ich wüsste nicht wirklich was ich mit einem

SELECT count(Frommser) FROM Fromms WHERE size >= 5000

machen sollte (size / mm)

Hotte

Tues Mit