php-resource



Zurück   PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr > Entwicklung > SQL / Datenbanken
 

Login

 
eingeloggt bleiben
star Jetzt registrieren   star Passwort vergessen
 

 

 


SQL / Datenbanken Probleme mit SQL? Hier könnt ihr eure Fragen zu SQL (MySQL, PostgreSQL, MS-SQL und andere ANSI-SQL Server) los werden.

Antwort
 
LinkBack Themen-Optionen Thema bewerten
  #1 (permalink)  
Alt 26-08-2009, 16:44
seekworld
 Registrierter Benutzer
Links : Onlinestatus : seekworld ist offline
Registriert seit: Mar 2006
Beiträge: 48
seekworld ist zur Zeit noch ein unbeschriebenes Blatt
Standard Fehler beim Autoincrement????

Hi,

(MySQL Version 5.0.45)

Ich hab einen ganz komischen Fehler:

Ich habe eine Tabelle mit

PHP-Code:
  id_elemnt INT(10UNSIGNED NOT NULL auto_increment,
  
id_terminal SMALINT(5UNSIGNED NOT NULL,
  
beschreibung text NOT NULL default '',
  
PRIMARY KEY idpk(id_terminalid_element
Das mit dem auto_increment funktionierte einwandfrei .... bis gestern.
Gestern habe ich nämlich Daten über PHPMyAdmin eingespielt, und zwar mit fixen id_element, weil ich mir da Daten offline vorbereitet habe.

Heute hat meine Webseite ganz ungewöhnliche Fehlermeldungen ausgespuckt, und Teile haben nicht mehr funktioniert, weswegen ich mal in der Datenbank nachgeschaut habe.

Das auto_increment machte dort weiter, wo es aufgehört hat, also bei id_element = 86. Die Daten die ich gestern manuell reingeklopft habe existieren für das auto_increment nicht (sollte eigentlich bei id_element = 166 weitermachen)

Der UNIQUE INDEX regt sich dabei allerdings nicht auf, weil die doppelten Einträge eine unterschiedliche id_terminal haben.

==> Darf das sein??
==> Wie kann ich das für die Zukunft verhindern? ...
==> Muß ich meine Index-Struktur neu überdenken? (wäre extrem sch*** weil die Webseite schon online ist, und sie hat sich als sehr gut herausgestellt)


Danke & lg,
seekworld
Mit Zitat antworten
  #2 (permalink)  
Alt 26-08-2009, 16:54
AmicaNoctis
  Moderatorin
Links : Onlinestatus : AmicaNoctis ist offline
Registriert seit: Jul 2009
Beiträge: 5.709
Blog-Einträge: 9
AmicaNoctis sorgt für eine eindrucksvolle AtmosphäreAmicaNoctis sorgt für eine eindrucksvolle Atmosphäre
Standard

Hallo,

das ist normal, wenn du den internen Zähler umgehst. Der wird aber automatisch neu ermittelt, wenn du den MySQL-Server neu startest. Du kannst ihn aber auch explizit ändern:
Code:
ALTER TABLE tabellenname AUTO_INCREMENT = 166;
Gruß,

Anja
Mit Zitat antworten
  #3 (permalink)  
Alt 26-08-2009, 17:00
h3ll
 Registrierter Benutzer
Links : Onlinestatus : h3ll ist offline
Registriert seit: Mar 2008
Beiträge: 3.578
h3ll befindet sich auf einem aufstrebenden Ast
Standard

Ich seh in deiner Tabellenstruktur keinen UNIQUE INDEX. Hast du was weggelassen?
Mit Zitat antworten
  #4 (permalink)  
Alt 26-08-2009, 17:49
seekworld
 Registrierter Benutzer
Links : Onlinestatus : seekworld ist offline
Registriert seit: Mar 2006
Beiträge: 48
seekworld ist zur Zeit noch ein unbeschriebenes Blatt
Standard

PRIMARY KEY ist UNIQUE wenn doppelte Einträge drinnen sind regt er sich auch auf .... Sorry für meine unklare Ausdrucksweise


Ich hab jetzt einbißchen herumprobiert.
Wenn ich beim id_terminal = 1 einen Wert hinzufüge zählt er bei 86 (mittlerweile 94) weiter
Wenn ich bei id_terminal = 2 einen Wert hinzufüge zählt er bei 166 weiter, also dort wo er eigentlich sollte.
Wieder bei id_terminal = 1 .... 95


Das ist entweder ein dicker fetter Bug, oder ein total bescheuertes absichtliches Verhalten.

PHP-Code:
ALTER TABLE tabellenname AUTO_INCREMENT 166
ist also auch keine Lösung auf die ich mich verlassen kann


Ich bin gerade dabei die Index-Struktur zu ändern *grmpf*
Dabei hab ich extra drauf geachtet, daß die Idizes so klein wie möglich sind, und zwecks der Performance die PRIMARY wo geht genommen, weil die die schnellsten sind


Danke für eure Hilfe
Mit Zitat antworten
  #5 (permalink)  
Alt 26-08-2009, 17:58
h3ll
 Registrierter Benutzer
Links : Onlinestatus : h3ll ist offline
Registriert seit: Mar 2008
Beiträge: 3.578
h3ll befindet sich auf einem aufstrebenden Ast
Standard

Das ist kein Bug, sondern ein gewünschtes Verhalten.

Du sagst:
PRIMARY KEY idpk(id_terminal, id_element)

Der Primary Key besteht also aus id_terminal und id_element. Es sind also folgende Kombinationen problemlos gleichzeitig möglich:

1,1
1,2
1,3
2,1
2,2
2,3
usw.

Das heißt es müssen nur beide Spalten zusammen eindeutig sein. Es darf zB. nicht zweimal 2,2 vorkommen, aber es kann sehr wohl 1,2 und 2,2 in der Tabelle vorhanden sein. Wenn du willst, dass die id_element für sich eindeutig ist, musst du id_terminal aus dem Primary Key rausnehmen.

Geändert von h3ll (26-08-2009 um 18:23 Uhr)
Mit Zitat antworten
  #6 (permalink)  
Alt 26-08-2009, 18:19
AmicaNoctis
  Moderatorin
Links : Onlinestatus : AmicaNoctis ist offline
Registriert seit: Jul 2009
Beiträge: 5.709
Blog-Einträge: 9
AmicaNoctis sorgt für eine eindrucksvolle AtmosphäreAmicaNoctis sorgt für eine eindrucksvolle Atmosphäre
Standard

Es gibt imho ohnehin keine sinnvolle Begründung, mit Mehrfeldprimärschlüsseln rumzumurksen. Jede solche Tabelle lässt sich so umformen, dass es nur noch eine Primärschlüsselspalte gibt.
Mit Zitat antworten
  #7 (permalink)  
Alt 26-08-2009, 18:38
wahsaga
  Moderator
Links : Onlinestatus : wahsaga ist offline
Registriert seit: Sep 2001
Beiträge: 25.236
wahsaga befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von seekworld Beitrag anzeigen
Das ist entweder ein dicker fetter Bug, oder ein total bescheuertes absichtliches Verhalten.
Letzteres. (Wobei, "total bescheuert" würde ich es eher nennen, sich über klar definiertes Verhalten aufzuregen ...)


MySQL :: MySQL 5.1 Reference Manual :: 3.6.9 Using AUTO_INCREMENT
Zitat:
For MyISAM tables you can specify AUTO_INCREMENT on a secondary column in a multiple-column index. In this case, the generated value for the AUTO_INCREMENT column is calculated as MAX(auto_increment_column) + 1 WHERE prefix=given-prefix. This is useful when you want to put data into ordered groups. [...]

In this case (when the AUTO_INCREMENT column is part of a multiple-column index), AUTO_INCREMENT values are reused if you delete the row with the biggest AUTO_INCREMENT value in any group.
__________________
I don't believe in rebirth. Actually, I never did in my whole lives.
Mit Zitat antworten
  #8 (permalink)  
Alt 26-08-2009, 19:26
seekworld
 Registrierter Benutzer
Links : Onlinestatus : seekworld ist offline
Registriert seit: Mar 2006
Beiträge: 48
seekworld ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Zitat:
Zitat von AmicaNoctis Beitrag anzeigen
Es gibt imho ohnehin keine sinnvolle Begründung, mit Mehrfeldprimärschlüsseln rumzumurksen.
Ich habe das jetzt so wie du geschrieben hats anders gemacht

Alt:
PHP-Code:
PRIMARY KEY mainkey (id_terminalid_element
Neu:
PHP-Code:
PRIMARY KEY id_element (id_element)
KEY mainkey (id_terminalid_element

Der Vorteil der alten Variante ist:
1) id_element wird nur in einem Index verwendet => Speicherplatz und Index-Größe, die man ja so klein wie möglich halten sollte. Gut in dem Fall könnte man es eventuell weglassen, aber das "Risiko" ist mir zu groß
2) der PRIMARY KEY ist der schnellste Index, weil er soviel ich weiß im Arbeitsspeicher liegt. Das beschleunigt also auch eine Abfrage nur nach id_terminal


Fortsetzung folgt.....
Mit Zitat antworten
  #9 (permalink)  
Alt 26-08-2009, 19:35
seekworld
 Registrierter Benutzer
Links : Onlinestatus : seekworld ist offline
Registriert seit: Mar 2006
Beiträge: 48
seekworld ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Zitat:
(Wobei, "total bescheuert" würde ich es eher nennen, sich über klar definiertes Verhalten aufzuregen ...)
Ich bezeichne es nachwievor bescheuert!
Wenn ich etwas auto_increment mache gehe ich als logisch denkender Mensch davon aus, daß immer(!) eins dazugezählt wird, also in sich schon UNIQUE ist, und nicht das Verhalten durch etwas anderes beeinflußt wird.

Nochdazu wird
PHP-Code:
ALTER TABLE tabellenname AUTO_INCREMENT 166
unbrauchbar

Das Verhalten hat, wie ich das jetzt sehe 2 Vorteile:
1) Der Benutzer sieht nicht wieviele Einträge sich insgesamt im System befinden
2) Beim händischen kopieren der Daten braucht man die id_element nicht verändern. Beim Kopieren mit einem UI kann man das allerdings programmiertechnisch leicht lösen, weshalb der Vorteil nicht wirklich zählt

Die Nachteile sind meines erachtens aber gewichtiger:
1) Die id_element ist im System nicht mehr UNIQUE
2) Ein logisches Verhalten wird durch ein anderes ersetzt, wenn man das in der Doku also übersehen hat so wie ich ....
3) Die oben genannte Tabelle ist die Haupttabelle der Elemente. Nachdem das System mehrsprachig ist gibt es eine 2te Tabelle
PHP-Code:
UNIQUE KEY (id_elementlanguage
die mit der Haupttabelle verknüpft ist.
.... Ich müßte also die id_terminal auch in diese Tabelle mitziehen und hätte damit redundante Daten, was der größte Fehler ist den man in einer Datenbankstruktur machen kann

lg,
seekworld
Mit Zitat antworten
  #10 (permalink)  
Alt 26-08-2009, 19:43
wahsaga
  Moderator
Links : Onlinestatus : wahsaga ist offline
Registriert seit: Sep 2001
Beiträge: 25.236
wahsaga befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von seekworld Beitrag anzeigen
Die Nachteile sind meines erachtens aber gewichtiger:
1) Die id_element ist im System nicht mehr UNIQUE
Das verlangen zu wollen, wenn man diese Spalte eben nicht explizit UNIQUE gemacht hat, sondern stattdessen einen aus mehreren Spalten zusammengesetzen Wert, wäre ja auch extrem abwegig.
__________________
I don't believe in rebirth. Actually, I never did in my whole lives.
Mit Zitat antworten
  #11 (permalink)  
Alt 26-08-2009, 19:45
h3ll
 Registrierter Benutzer
Links : Onlinestatus : h3ll ist offline
Registriert seit: Mar 2008
Beiträge: 3.578
h3ll befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von seekworld Beitrag anzeigen
1) Der Benutzer sieht nicht wieviele Einträge sich insgesamt im System befinden
Das hat überhaupt nix mit dem AUTO INCREMENT zu tun.

Ich schreibe Datensatz 1, 2 und 3 in die Datenbank. Dann lösche ich Datensatz 1 heraus. Dem AUTO INCREMENT entnehme ich, dass 3 Datensätze vorhanden sein müssen, was aber nicht stimmt!

Zitat:
Zitat von seekworld Beitrag anzeigen
1) Die id_element ist im System nicht mehr UNIQUE
Du hast es nicht als UNIQUE definiert! Du willst MySQL deine eigenen Fehler in die Schuhe schieben.

Zitat:
Zitat von seekworld Beitrag anzeigen
2) Ein logisches Verhalten wird durch ein anderes ersetzt, wenn man das in der Doku also übersehen hat so wie ich ....
Dein "logisches Verhalten" ist für mich aber unlogisch, und ich hab die Stelle im Handbuch noch nie gelesen.

Zitat:
Zitat von seekworld Beitrag anzeigen
3) Die oben genannte Tabelle ist die Haupttabelle der Elemente. Nachdem das System mehrsprachig ist gibt es eine 2te Tabelle
PHP-Code:
UNIQUE KEY (id_elementlanguage
die mit der Haupttabelle verknüpft ist.
.... Ich müßte also die id_terminal auch in diese Tabelle mitziehen und hätte damit redundante Daten, was der größte Fehler ist den man in einer Datenbankstruktur machen kann
Quatsch mit Sauce. Verwende wirklich eindeutige IDs und keine Kombinationen aus mehreren Spalten, dann gibts das Problem erst gar nicht.
Mit Zitat antworten
  #12 (permalink)  
Alt 26-08-2009, 19:58
AmicaNoctis
  Moderatorin
Links : Onlinestatus : AmicaNoctis ist offline
Registriert seit: Jul 2009
Beiträge: 5.709
Blog-Einträge: 9
AmicaNoctis sorgt für eine eindrucksvolle AtmosphäreAmicaNoctis sorgt für eine eindrucksvolle Atmosphäre
Standard

Zitat:
Zitat von seekworld Beitrag anzeigen
Wenn ich etwas auto_increment mache gehe ich als logisch denkender Mensch davon aus, daß immer(!) eins dazugezählt wird
Als ebenfalls logisch denkender Mensch, gehe ich davon aus, dass "automatisch" nicht "immer" heißt, sondern nur, dass es vom System "selbst" entschieden wird. Wenn du aber fremde Daten mit festen Primärschlüsselwerten importierst, verhinderst du diesen Automatismus. Dann gilt: wer die Ordnung stört, muss auch selbst dafür sorgen, dass sie wieder hergestellt wird.

Zitat:
Zitat von seekworld Beitrag anzeigen
Die id_element ist im System nicht mehr UNIQUE
Weil du sie nicht als unique spezifiziert hast, jedenfalls nicht unabhängig von anderen Spalten. Dass sie vorher eindeutig war, war nur ein schöner Zufall. Wenn du dich drauf verlassen willst, musst du nen Unique Index erstellen, so einfach ist das.

Zitat:
Zitat von seekworld Beitrag anzeigen
Ich müßte also die id_terminal auch in diese Tabelle mitziehen und hätte damit redundante Daten, was der größte Fehler ist den man in einer Datenbankstruktur machen kann
Das verhindert man am besten, wenn man die DB von anfang an richtig plant und nur Einfeldschlüssel benutzt. Wer sich Gedanken drüber macht, ob der Primary Key der schnellste ist, spart eindeutig an der falschen Stelle, wenn er dann Mehrfeldschlüssel reinbringt.

Das sind nur mal so meine Gedanken dazu...


Edit: Oh, ich war aber langsam, steht ja praktisch alles schon da...

Geändert von AmicaNoctis (26-08-2009 um 20:00 Uhr)
Mit Zitat antworten
  #13 (permalink)  
Alt 26-08-2009, 22:29
seekworld
 Registrierter Benutzer
Links : Onlinestatus : seekworld ist offline
Registriert seit: Mar 2006
Beiträge: 48
seekworld ist zur Zeit noch ein unbeschriebenes Blatt
Standard

@wahsaga
Natürlich hast du recht, daß ich dies Spalte nicht UNIQUE gemacht habe, also durch manuelles einpflegen auch doppelte Einträge schreiben könnte, ohne das sich MySQL aufregen würde.
Daß er automatisch doppelte Einträge in der auto_increment - Spalte produziert, ist der Nachteil den ich meine


@h3ll,
@AmicaNoctis

Vielleicht solltet ihr euch das Posting von "wahsaga", der immer wieder eine Hilfe ist, durchlesen ....
=> Das verhalten von auto_increment wird durch den mehrspaltigen PRIMARY KEY verändert ..... und das überliest man bei dem Umfang der Doku ganz leicht, was mein einziger Fehler war.

Beim kopieren der Daten habe ich weder einen Fehler gemacht noch den Automatismus gestört, da er ja nachwievor "richtig" funktioniert. Richtig im Sinne der MySQL-Doku, aber "unrichtig" nach gängigem mathematischen und logischen Verständnis, und nicht wie das jahrelang gewohnte Verhalten von MySQL


@AmicaNoctis
PHP-Code:
Das verhindert man am bestenwenn man die DB von anfang an richtig plant und nur Einfeldschlüssel benutzt
Die Datenbankstruktur ist perfekt! :(
Auch die Indexstruktur war perfekt, bis zu diesem blöden Verhalten. Jedenfalls hab ich mit der Abfragedauer und EXPLAIN die besten Werte erziehlt.

Nur einspaltige Indexe?
Dir scheint entgangen zu sein, daß MySQL nur einen Index zur Eingrenzug der Daten hernimmt, bevor er auf die eigentlichen Daten zugreift. Die mehrspaltigen Indexe haben schon ihren Sinn!

Falls du "einspaltige PRIMARY KEYS" meinst...
Wenn es etwas schnelleres gibt, als den normalen INDEX ... wieso sollte man das nicht verwenden?
Das wäre, wie wenn du einen 100Euro-Schein, der auf der Straße liegt einfach liegen läßt ....

Geändert von seekworld (26-08-2009 um 22:49 Uhr)
Mit Zitat antworten
  #14 (permalink)  
Alt 26-08-2009, 22:38
h3ll
 Registrierter Benutzer
Links : Onlinestatus : h3ll ist offline
Registriert seit: Mar 2008
Beiträge: 3.578
h3ll befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von seekworld Beitrag anzeigen
Falls du "einspaltige PRIMARY KEYS" meinst...
Wenn es etwas schnelleres gibt, als den normalen INDEX ... wieso sollte man das nicht verwenden?
Das wäre, wie wenn du einen 100Euro-Schein, der auf der Straße liegt einfach liegen läßt ....
Du versuchst immer noch am falschen Ende zu optimieren. Sorge einfach dafür, dass ein Datensatz eine eindeutige ID hat und nur dieser ID für den Primary Key verwendet wird.

Und nein, das Datenbankdesign ist nicht perfekt.
Mit Zitat antworten
  #15 (permalink)  
Alt 26-08-2009, 23:21
seekworld
 Registrierter Benutzer
Links : Onlinestatus : seekworld ist offline
Registriert seit: Mar 2006
Beiträge: 48
seekworld ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Zitat:
Und nein, das Datenbankdesign ist nicht perfekt.
Das finde ich total vermessen anhand einer Demo-Tabelle, die mein Problem beschreibt, auf das ganze Datenbankstruktur zu schließen.

Zitat:
Du versuchst immer noch am falschen Ende zu optimieren.
Woraus schließt du das?
War es überhaupt ein falsches Ende, wenn es merklich Performance gebracht hat?

Zitat:
Sorge einfach dafür, dass ein Datensatz eine eindeutige ID hat und nur dieser ID für den Primary Key verwendet wird.
Ich weiß nicht wie ich diese Aussage interpretieren soll. Meinst du, daß ich die Indizes bei der aktuellen Datenbank ändern soll? Das habe ich längst gemacht, wie bereits zuvor geschrieben!
Mit Zitat antworten
Antwort

Lesezeichen


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Fehler beim Speichen chrescht PHP Developer Forum 5 05-08-2005 15:48
fehler beim includen ! launebaer PHP Developer Forum 2 22-02-2005 10:38
autoincrement id soll beim speichern des Datensatzes zurückgegeben werden Thommy SQL / Datenbanken 3 04-10-2001 16:51
autoincrement id soll beim speichern des Datensatzes zurückgegeben werden Thommy PHP Developer Forum 2 04-10-2001 06:29
autoincrement -Feld erzeugt Fehler bei Eingabe norbert PHP Developer Forum 1 10-08-2001 11:32

Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


PHP News

ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlicht
ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlichtDie bekannte Marktplatzsoftware ebiz-trader ist in der Version 7.5.0 veröffentlicht worden.

28.05.2018 | Berni

Wissensbestand in Unternehmen
Wissensbestand in UnternehmenLebenslanges Lernen und Weiterbilden sichert Wissensbestand in Unternehmen

25.05.2018 | Berni


 

Aktuelle PHP Scripte

PHP Server Monitor

PHP Server Monitor ist ein Skript, das prüft, ob Ihre Websites und Server betriebsbereit sind.

11.09.2018 Berni | Kategorie: PHP/ Security
PHP WEB STATISTIK ansehen PHP WEB STATISTIK

Die PHP Web Statistik bietet Ihnen ein einfach zu konfigurierendes Script zur Aufzeichnung und grafischen und textuellen Auswertung der Besuchern Ihrer Webseite. Folgende zeitlichen Module sind verfügbar: Jahr, Monat, Tag, Wochentag, Stunde Folgende son

28.08.2018 phpwebstat | Kategorie: PHP/ Counter
Affilinator - Affilinet XML Produktlisten Skript

Die Affilinator Affilinet XML Edition ist ein vollautomatisches Skript zum einlesen und darstellen der Affili.net (Partnerprogramm Netzwerk) Produktlisten und Produktdaten. Im Grunde gibt der Webmaster seine Affilinet PartnerID ein und hat dann unmittelb

27.08.2018 freefrank@ | Kategorie: PHP/ Partnerprogramme
 Alle PHP Scripte anzeigen

Alle Zeitangaben in WEZ +2. Es ist jetzt 11:39 Uhr.