phpMyAdmin Fehler
lima-city → Forum → Programmiersprachen → PHP, MySQL & .htaccess
auto
befehl
betreff
code
datenbank
datensatz
datum
definieren
definition
feld
grund
nachricht
not
null
referenz
regel
setzen
spalte
spalten
tabelle
-
phpMyAdmin meldet #1075 - Incorrect table definition; there can be only one auto column and it must be defined as a key wenn ich eine Tabelle erstellen will, der SQL-Befehl sieht so aus:
SQL-Befehl: CREATE TABLE `mails` ( `id` INT NOT NULL AUTO_INCREMENT , `user` VARCHAR( 50 ) NOT NULL , `titel` VARCHAR( 50 ) NOT NULL , `nachricht` TEXT NOT NULL , `von` VARCHAR( 50 ) NOT NULL , `an` VARCHAR( 50 ) NOT NULL );
Was ist falsch?
//Titel geändert
Beitrag geändert: 22.8.2008 10:32:57 von sebigisler -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
du musst id noch als Primärschlüssel (primarykey) setzen
-
Wie mach cih das, und was ist ein Primärschlüssel? Ich bin noch ziehmlich neu auf dem Gebiet Datenbank. Warum muss ich das mit den anderen nicht machen?
-
Soweit ich weis legt MySQL einfach fest dass Auto-Inkrementierte Felder ein Primärschlüssel sein müssen, warum genau das so ist weis ich leider selbst nicht und wie du das in deinem Code machst auch nicht (ich erstelle meine Datenbanken normalerweise nicht über code sondern "per Hand" also manuell)
aber google doch einfach mal nach "mysql feld primärschlüssel code"
ich hab das nicht überprüft aber ich bin zuversichtlich dass du mit etwas geduld ein vernünftiges ergebnis finden wirst
Beitrag geändert: 18.8.2008 22:20:05 von projektverwaltung -
AUTO_INCREMENT-Felder müssen Primärschlüssel sein, da im Allgemeinen die Regel gilt:
UNIQUE + NOT NULL = PRIMARY KEY
Dies wird bei einer AUTO_INCREMENT-Spalte auch erfüllt, da automatisch der nächste noch nicht verwendete Wert genutzt wird und sie so auch auf keinem Fall den Wert NULL annehmen kann.
Es sollte eigentlich auch generell logisch erscheinen, dass man AUTO_INCREMENT nur bei Primärschlüsseln, genauer bei künstlichen Primärschlüsseln verwendet. Diese verwendet man sowieso nur dann, wenn man kein anderes Feld für den Primärschlüssel verwenden kann oder diese allein nicht ausreichen.
Definieren kannst du Primärschlüssel über PRIMARY KEY (spalten). Für spalten kann man alle zum Primärschlüssel gehörigen Spalten durch ein Komma getrennt einsetzen.
Speziell auf deine Tabelle angewandt, würde der SQL-Query dann wie folgt aussehen:
CREATE TABLE mails ( id INT NOT NULL AUTO_INCREMENT, user VARCHAR(50) NOT NULL, titel VARCHAR(50) NOT NULL, nachricht TEXT NOT NULL, von VARCHAR(50) NOT NULL, an VARCHAR(50) NOT NULL, PRIMARY KEY (id) );
-
Ist das völlig egal, ob man den Primärschlüssel direkt an die Spalte schreibt, die zum Primärschlüssel gemacht werden soll, oder ob man das erst unten einträgt?
Grund: Grammatikfehler
Beitrag geändert: 21.8.2008 9:28:43 von my-selfmade -
Ein Primarschlüssel dient der eindeutigen Identifizierung eines Datensatzes in einem Datentyp. Das kann ein Name eines Kunden sein, eine eMail Adresse etc. Da der Schlüssel zur _eindeutigen_ Identifizierung genutzt wird, darf er logischerweise bei einem Datensatz nicht fehlen (NOT NULL) und muss eindeutig sein, also nur einmal vorkommen (UNIQUE). Daraus ergibt sich (wie bereits erwähnt), dass Datensätze die beide eigenschaften aufweisen automatisch als PRIMARYKEY definiert werden.
Beim Design eines Datentypes sollte darauf geachtet werden, dass keine künstlischen Primärschlüssel geschaffen werden, da diese nur den Speicherplatz verbrauchen und verwirren können. In deinem Fall benutzt du den Datentyp Integer als Primärschlüssel. Er hat je nach system 16, 32 oder 64 bit länge. Bei 1 000 000 Einträgen würde das einen unnötigen Speicherplatz von einigen MB ausmachen. Es fällt zwar kaum ins Gewicht gilt aber trotzdem als unschön.
Um eine eMail eindeutig zu Identifizieren würde meiner Ansicht nach eine Verbindung der Datensätze Betreff und einem Datum ausreichen.
SELECT * FROM mails
WHERE titel="Betreff" AND
AND date='2008-12-10 14:12:09'
;
PS: Dies soll keine Kritik an dein Design sein. Eigentlich wollte ich nur die Bedeutung eines Primärykeys näherbringen, ich persönlich nutze IDs auch oft obwohl man das eigentlich nicht machen sollte... -
Ist das völlig egal, ob man den Primärschlüssel direkt an die Spalte schreibt, die zum Primärschlüssel gemacht werden soll, oder ob man das erst unten einträgt?
Grund: Grammatikfehler
Grundsätzlich ist zumindest in MySQL beides möglich. Richtig bzw. bevorzugt ist aber eigentlich die Schreibweise am Ende, welche auch mehr Sinn macht, speziell, wenn man mehrere Spalten als ein Primärschlüssel definieren möchte.
Auch nachzulesen in der MySQL-Referenz. Grundsätzlich kommen zunächst die Definitionen der Spalten, gefolgt von den Constraints, wie bspw. PRIMARY KEY, INDEX, UNIQUE, etc.
Jedoch sollte bei diesen Constraints darauf geachtet werden, dass MySQL (noch) nicht den gesamten SQL-Standard unterstützt, aber versucht, so gut wie möglich kompatibel zu sein und ignoriert dann einfach nicht unterstützte Elemente. Ein Beispiel dafür wäre das CHECK-Constraint.
Hier die Definition aus der MySQL-Referenz:
[CONSTRAINT [symbol]] PRIMARY KEY [index_type] (index_col_name,...)
(Alles in eckigen Klammern sind optionale Elemente.)
Zu den künstlichen Schlüsseln:
Klar sollte sein, dass man in einem guten Datenbankdesign so wenige künstliche Schlüssel wie möglich verwenden sollte. Also nur dann, wenn es nicht anders geht.
Diese erscheinen vielleicht einfacher zu händeln, sind aber nur zusätzliche und unnötige Daten in der Datenbank. Selbst wenn man zum Beispiel einen String als Primärschlüssel verwendet und ihn dann später als Fremdschlüssel nutzen möchte, so ist dies auch überhaupt kein Problem, da dieser Fremdschlüssel (in der Regel) nur eine Referenz auf das eigentliche Datum ist - alles andere wären nur redundante Daten, was man ja vermeiden möchte.
Dazu sollte man aber auch erwähnen, dass MySQL nur im InnoDB-Engine den FOREIGN KEY-Constraint unterstützt. In späteren Versionen wird sich das vielleicht noch ändern, wer weiß das schon genau, jedoch sind innerhalb von MySQL da noch an der ein oder anderen Stelle ein paar Sachen zu beachten.
Nutzt man dort eine andere Engine, könnte man schon auf Grund der geringeren Speichergröße auf künstliche Schlüssel ausweichen, sollten sie als Fremdschlüssel bzw. zum in Beziehung setzen (sind ja dort keine wirklichen Fremdschlüssel) verwendet werden .
Wie mehrfach erwähnt, gibt es derzeit noch einige Lücken in MySQL, wodurch man da an ein paar Stellen ein wenig aufpassen muss. Die MySQL-Refernenz hilft da aber mit Sicherheit weiter, welche unter http://dev.mysql.com/doc/ zu finden ist (in Deutsch bisher bis zur Version 5.1, 6.0 wird sicherlich noch folgen).
-
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
