nicht angemeldet
Wie weise ich einem Datensatz(MySQL) einen Autowert zu?
Hallo!
Ich würde Datensätzen gerne automatisch einen Autowert wie in Access möglich zuweisen?
Wie funktioniert das?
Geht das auch mit phpmyadmin?
Vielen Dank nochmal für Eure schnelle Hilfe gerade!
Gruß
Andreas
-
Ich würde Datensätzen gerne automatisch einen Autowert wie in
Access möglich zuweisen?Kenne Access leider nicht, was ist ein Autowert? Daimler, VW? :)
Nein, ernsthaft: du kannst beim Erstellen oder Ändern einer Tabelle die Schlüsselwörter DEFAULT und AUTO_INCREMENT angeben. Ersterer ist eine Vorgabe, falls bei INSERT nichts angegeben wird, letzterer erhöt den Wert automatisch mit jeder neuen Zeile.
Details dazu stehen in der MySQL-Anleitung (wo sonst).Geht das auch mit phpmyadmin?
Ja. Ich hab's jetzt gerade nicht zur Hand, aber du hast da irgendwo unter Eigenschaften einer Tabelle ein Feld DEFAULT und ein's mit AUTO_INCREMENT.
Gruß,
soenk.e -
Hallo!
Ich würde Datensätzen gerne automatisch einen Autowert wie in Access möglich zuweisen?
Wie funktioniert das?
Geht das auch mit phpmyadmin?Mal ein Tipp, daß Dir nicht das selbe passiert wie mir. Wenn Du eine mySQL eines Providers nutzt, also richtig online ;-), schaue mal nach der Version.
SELECT VERSION();
mySQL kann erst seit Version 3.23 einen "richtige" eindeutige ID vergeben. Mit der Version 3.22 kann es nähmlich zu schweren Fehlern kommen, also die Integrität Deiner Datensätz ist nicht gewahrt.
Bsp:
100
101
102
103Löschst Du nun 102 geht es mit 104 weiter, normal... Löschst Du aber 103, geht es mit 103 weiter und nicht mit 104.
Schlund zum Beispiel arbeitet noch mit der mySQL Version 3.22.21.
Als Abhilfe hilft Dir hier eine zweite Tabelle, eine Art Dummytabelle, in der Du immer eine Zahl um eins erhöhst und die dann als ID verwendest.
Bei eine Tabelle ist das kein Problem. Sobald Du aber mehrere Tabellen hast und die IDs als Referenz benutzt, kann das ganz schön in die Hose gehen.
Bis 3.23 wurde der Tabellentyp ISAM verwendet, jetzt standardmäßig MYISAM. Berichten zu Folge, liegt das an den Tabellentype ISAM.
MfG, André Laugks
-
Hallo,
100
101
102
103
Löschst Du nun 102 geht es mit 104 weiter, normal... Löschst Du aber 103, geht es mit 103 weiter und nicht mit 104.
Als Abhilfe hilft Dir hier eine zweite Tabelle, eine Art Dummytabelle, in der Du immer eine Zahl um eins erhöhst und die dann als ID verwendest.
Bei eine Tabelle ist das kein Problem. Sobald Du aber mehrere Tabellen hast und die IDs als Referenz benutzt, kann das ganz schön in die Hose gehen.Das problem als solches kann in der praxis bei sauberen löschroutinen nicht auftreten, wie fast immer ist wiedermal der Verstand des programmieres gefragt.
Wer nur teilbestände löscht, und nicht alle betrofenen tabellen updatet wird immerwieder probleme haben.
Aber das ist wohl was, daß man erst lernt wenn es einem das erste mal passiert ist :))my 2cents
Ludwig-
Hallo!
Das problem als solches kann in der praxis bei sauberen löschroutinen nicht auftreten, wie fast immer ist wiedermal der Verstand des programmieres gefragt.
Wer nur teilbestände löscht, und nicht alle betrofenen tabellen updatet wird immerwieder probleme haben.
Aber das ist wohl was, daß man erst lernt wenn es einem das erste mal passiert ist :))Du hast sicherlich Recht!
Bei mir stand die ID aber also einer Art Loginnummer(keine User_ID). Man konnte sich mit dieser Nummer was ansehen. Wenn man da die letzte löscht und wieder eine vergibt kann es zu Verwechslungen führen. Nicht mal mit einer zweiten Spalten, also SELECT MAX(spalte)+1 FROM tabelle, kann man da was machen und das als "ID" verwenden. Den sobald man wieder den letzten Datensatz löscht, haut das mit dem Max nicht mehr hin.
Was ist, wenn Du nach extern Links wie http://www.domain.de/seite.phtml?variable=101 raus gibst. Nun löschst Du die 101 und legst einen neuen Artikel mit 101 an....
Klar, wenn ich durch alle Tabellen gehe und alles lösche, was mit der 101 zu tun hat, gibt es keine Integritätsprobleme. Nur sobald extern was mit im Spiel ist, haut das nicht mehr hin. Und IMHO ist das eine Feature einer jeden Datenbank, ein Spaltentype zu haben, der sicher immer eine fortlaufende Nummer generieret, egal ob man die letzte ID generiert.
Hier im Forum werden die Artikel ja auch mit fortlaufenden Nummern nummeriert. Was ist nun, wenn mal ein Link von aussen hier her geht? Dann stimmen einige Suchmaschineneinträge(extern) nicht mehr, wenn man daran was ändert.Also ein Artikel auf einmal die ID eines anderen Artikels bekommt.
MfG, André Laugks
-
Hoi,
Was ist, wenn Du nach extern Links wie http://www.domain.de/seite.phtml?variable=101
raus gibst. Nun löschst Du die 101 und legst einen neuen Artikel mit 101 an....Du solltest vielleicht ueber Artikel-Nummern nachdenken ;-)
Klar, wenn ich durch alle Tabellen gehe und alles lösche, was mit der 101 zu tun hat, gibt
es keine Integritätsprobleme.Das sollest du eh machen. Allein um der Integritaet willen. Stell dir vor, du machst einen JOIN
und nimmst eben diese ID als Filterkriterium -- tja, bei unsauberen Loeschungen kommt es
jetzt zu NULL-Datensaetzen.Nur sobald extern was mit im Spiel ist, haut das nicht mehr hin.
Warum?
Und IMHO ist das eine Feature einer jeden Datenbank, ein Spaltentype zu haben, der
sicher immer eine fortlaufende Nummer generieret, egal ob man die letzte ID generiert.Nein. Das ist kein Aufgabengebiet einer DB.
Hier im Forum werden die Artikel ja auch mit fortlaufenden Nummern nummeriert.
Von hand.
Was ist nun, wenn mal ein Link von aussen hier her geht? Dann stimmen einige
Suchmaschineneinträge(extern) nicht mehr, wenn man daran was ändert. Also ein
Artikel auf einmal die ID eines anderen Artikels bekommt.Nicht alles, was hinkt, ist ein Vergleich ;-) Ich glaube nicht, dass man ein Forum mit einem
Shopping-System vergleichen kann.Gruesse,
CK-
Hallo,
Nur sobald extern was mit im Spiel ist, haut das nicht mehr hin.
Warum?Sowas lässt sich leicht umgehen, indem man nicht die ID nach aussen gibt, sondern eine Session ID, und diese Session id ist wiederum mit der echten ID verlinkt, löscht man die ID, muss auch die Session gelöscht werden. Kommt nun einer mit einer nicht mehr vorhandenen Session an, lenkt man ihn auf eine art 404 seite um, mit der info das es diesen artikel eben nicht mehr gibt. (gelöscht ist eben gelöscht) und somit wären wir wieder bei der grundaussage, sauberes löschen *g*
Es ist natürlich vom anwendungsgebiet abhängig, aber generell werden nur wirklich solche ids nach aussen kommuniziert die auch bestand haben, und zu keinem sicherheitsproblem führen.
lg
Ludwig-
Moin,
Sowas lässt sich leicht umgehen, indem man nicht die ID nach aussen gibt, sondern eine
Session ID, und diese Session id ist wiederum mit der echten ID verlinkt, löscht man die ID,
muss auch die Session gelöscht werden. Kommt nun einer mit einer nicht mehr vorhandenen
Session an, lenkt man ihn auf eine art 404 seite um, mit der info das es diesen artikel eben
nicht mehr gibt. (gelöscht ist eben gelöscht) und somit wären wir wieder bei der
grundaussage, sauberes löschen *g*ACK.
Oder man nimmt eben die Artikel-Nummern direkt -- was eigentlich IMHO viel sinnvoller ist.Aber meine Frage bezog sich auf was komplett anderes: Warum sollte sauberes Loeschen nicht
moeglich sein, wenn etwas 'externes' im Spiel ist? Hierbei waere noch zu klaeren, was das 'externe'
sein soll.Es ist natürlich vom anwendungsgebiet abhängig, aber generell werden nur wirklich solche ids
nach aussen kommuniziert die auch bestand haben, und zu keinem sicherheitsproblem führen.ACK.
Gruesse,
CK-
Hallo zusammen!
Vielleicht nochmal kurz zu meinem Problem:
Ich glaube kaum das das in meiner DB zu Problemen führt, da ich ertmal nur die eine Tabelle verwende, kpl. Bestellung am Ende sowieso lösche und in eine txt schreibe, die kann viel besser offline verwendet werden, da es eine DB beim Hoster ohne ODBC Zugriff ist. (gibt es eigentlich eine Möglichket den csv Export wie in phpMyAdmin zu automatisieren??)
Außerdem verwende ich sowohl die SessionID UND die ID zum auswählen, da sollte es dann wohl keine Überschneidungen geben, und wenn ein Produkt aus dem Warenkorb soll, wird halt der kpl. Datensatz gelöscht!Gruß
Andreas
-
-
Hallo!
Sowas lässt sich leicht umgehen, indem man nicht die ID nach aussen gibt, sondern eine Session ID, und diese Session id ist wiederum mit der echten ID verlinkt, löscht man die ID, muss auch die Session gelöscht werden...
Es ist natürlich vom anwendungsgebiet abhängig, aber generell werden nur wirklich solche ids nach aussen kommuniziert die auch bestand haben, und zu keinem sicherheitsproblem führen.
siehe Erklärung des Systems: <?m=7162&t=1135>
Ich hatte auch an eine Session-ID/uniqid-ID[md5(uniqid (rand()));] gedacht. Nur ist so etwas schwer einzutippen. Nicht immer kann man sowas per Email einem zusenden.MfG, André Laugks
-
-
Hallo!
Du solltest vielleicht ueber Artikel-Nummern nachdenken ;-)
Die ganze Sache ist kein Shop, sondern eine Art Präsentationssystem. Der Kunde bekommt eine Nummer und kann sich dann was anschauen.
An eine Art Artikelnummer hatte ich auch gedacht. Nur sollte es eine Nummer sein, die sehr einfach ist. Hier geht es nicht um geheime Sachen, also alles ohne Passwort und Benutzername. Hier war also eine fortlaufende Nummer die beste und einfachste Lösung. Was liegt also nahe, man nehem die "AUTO_iNCREMENT-ID".
Klar, wenn ich durch alle Tabellen gehe und alles lösche, was mit der 101 zu tun hat, gibt
es keine Integritätsprobleme.Das sollest du eh machen. Allein um der Integritaet willen. Stell dir vor, du machst einen JOIN
und nimmst eben diese ID als Filterkriterium -- tja, bei unsauberen Loeschungen kommt es
jetzt zu NULL-Datensaetzen.Richtig. Nur mySQL bietet keine Transaktionen oder Foreign Keys. Ich kann also nur hoffen, das alles gelöscht wird oder das gemacht wird, was ich vor habe zu tun SELECT, INSERT und UPDATE aufeinmal. Klar, nachdem ich glaube alles gelöscht zu haben, kann man ja noch einmal mit einem oder mehreren Selects nach schauen. Mal abgesehen von den vielen DB-Anfrage.
Nur sobald extern was mit im Spiel ist, haut das nicht mehr hin.
Warum?Nehmen wir mal an, ein Link auf ein Zeitungsartikel, den ich auf einer anderen seite einfüge. Nun linke ich auf ein Artikel über Kindererziehung und nach einer Zeit steht hinter dem selben Link ein Artikel über Hodenkrebs bei Elefanten. ;-)
Und IMHO ist das eine Feature einer jeden Datenbank, ein Spaltentype zu haben, der
sicher immer eine fortlaufende Nummer generieret, egal ob man die letzte ID generiert.Nein. Das ist kein Aufgabengebiet einer DB.
Sorry, ich habe mich falsch ausgedrück/"geschrieben". Ich meinte, eine DB hat die aufgabe ein Spaltentype oder Feature zu bieten, das fortlaufende IDs generiert.
Hier im Forum werden die Artikel ja auch mit fortlaufenden Nummern nummeriert.
Von hand.
Aber Ihr habt doch die letzte vergebene ID irgendwo zu stehen?!
Was ist nun, wenn mal ein Link von aussen hier her geht? Dann stimmen einige
Suchmaschineneinträge(extern) nicht mehr, wenn man daran was ändert. Also ein
Artikel auf einmal die ID eines anderen Artikels bekommt.Nicht alles, was hinkt, ist ein Vergleich ;-) Ich glaube nicht, dass man ein Forum mit einem
Shopping-System vergleichen kann.Mir ist nichts besseres eingefallen ;-). Ich meinte Links in der Suchmaschine zum Archiv zum Beipiel.
MfG, André Laugks
-
-
-
-