MySQL autoincrement-Feld manuell um 1 erhöhen

[Markus]

Hi, weiß jemand, wie ich ein autoincrement-Feld manuell für alle Datensätze erhöhe?

Folgende Aufgabe habe ich: Ich habe eine Tabelle account, in der im Feld id (autoincrement) die Account-IDs gespeichert sind. Jetzt möchte ich die ID 1 wieder freischaufeln, deswegen versuche ich folgendes:

UPDATE account SET id = id + 1

woraufhin ich

1062: Duplicate entry '2' for key 1

erhalte. Offenbar versucht MySQL die Query beim ersten Datensatz beginnend auszuführen. Also implizit:

UPDATE account SET id = id + 1 WHERE id = 1
UPDATE account SET id = id + 1 WHERE id = 2
UPDATE account SET id = id + 1 WHERE id = 3
usw.

Das schlägt dann natürlich fehl :(
Danke für alle Anregungen!
Markus

[wahsaga]

hi,

Hi, weiß jemand, wie ich ein autoincrement-Feld manuell für alle Datensätze erhöhe?

Warum willst du das?

Folgende Aufgabe habe ich: Ich habe eine Tabelle account, in der im Feld id (autoincrement) die Account-IDs gespeichert sind. Jetzt möchte ich die ID 1 wieder freischaufeln,

Definiere "wieder freischaufeln".

Wurde der Datensatz mit der ID 1 gelöscht?
Wenn ja, warum willst du einen neuen mit der ID 1 anlegen? So etwas macht man nicht™.
Die ID hat die Aufgabe einen Datensatz eindeutig zu identifizieren, nicht mehr und nicht weniger.
Sie erneut zu vergeben, wäre absoluter Unfug.

deswegen versuche ich folgendes:
UPDATE account SET id = id + 1
woraufhin ich
1062: Duplicate entry '2' for key 1
erhalte. Offenbar versucht MySQL die Query beim ersten Datensatz beginnend auszuführen.

Nicht nur beim "ersten", sondern bei allen natürlich - schließlich hast du ja gar keine Einschränkung angegeben, bei welchen Datensätzen du das Update durchführen möchtest.

gruß,
wahsaga

[Markus]

Hi wahsaga,

Warum willst du das?

ganz einfach: ich möchte für Spezialaccounts (admin, anonymous usw.) einen Bereich im Range von 1-100 reservieren. Und das in einer bestehenden Datenbank, wo diese IDs bereits belegt wurden. Der Grund ist die pure Übersichtlichkeit und das man dann so eine Sachen machen kann wie "UPDATE account SET x = y WHERE id <= 100"

Definiere "wieder freischaufeln".

s.o.

Wenn ja, warum willst du einen neuen mit der ID 1 anlegen? So etwas macht man nicht™.

Ja, Papa ;) Spaß beiseite: ich bin kein MySQL- oder Datenbank-Neuling und das ist schon wohlüberlegt. Nur in diesem speziellen Fall eines Autoincrement-Feldes bin ich unsicher.

erhalte. Offenbar versucht MySQL die Query beim ersten Datensatz beginnend auszuführen.

Nicht nur beim "ersten", sondern bei allen natürlich

Klaro, deswegen schrieb ich ja auch "beginnend".

Danke und Grüße,
Markus

[MudGuard]

Hi,

Warum willst du das?
ganz einfach: ich möchte für Spezialaccounts (admin, anonymous usw.) einen Bereich im Range von 1-100 reservieren. Und das in einer bestehenden Datenbank, wo diese IDs bereits belegt wurden. Der Grund ist die pure Übersichtlichkeit und das man dann so eine Sachen machen kann wie "UPDATE account SET x = y WHERE id <= 100"

Welchen Typ hat die id?

Falls integer, könntest Du negative Werte für Deine Spezial-Datensätze benutzen.

Ja, Papa ;) Spaß beiseite: ich bin kein MySQL- oder Datenbank-Neuling und das ist schon wohlüberlegt.

So klingt das aber nicht.

cu,
Andreas

[Markus]

Welchen Typ hat die id?

Autoincrement-Felder sind immer Integer-Felder.

Falls integer, könntest Du negative Werte für Deine Spezial-Datensätze benutzen.

Nein, das geht nicht. Jedenfalls nicht bei MySQL:
http://dev.mysql.com/doc/refman/4.0/de/upgrading-from-3-22.html

"AUTO_INCREMENT funktioniert nicht mit negativen Zahlen. Der Grund liegt darin, dass negative Zahlen beim Übergang von -1 auf 0 Probleme verursachen."

Ja, Papa ;) Spaß beiseite: ich bin kein MySQL- oder Datenbank-Neuling und das ist schon wohlüberlegt.

So klingt das aber nicht.

Sag mal, geht es eigentlich noch billiger, Du Experte (siehe oben)? In zwei Sätzen hast Du mir zwei falsche Tipps gegeben.

Das wäre ja völlig in Ordnung und ich täte einen Teufel, jemandem der mir helfen möchte seine unqualifizierten Antworten auch noch unter die Nase zu reiben, aber wenn jemand so bescheuert daher kommt ("So klingt das aber nicht."), braucht er sich nicht wundern.

Wie auch immer: Inwiefern war meine Frage denn bitte unberechtigt oder unprofessionell?

Beste Grüße, Markus

[MudGuard]

Hi,

Autoincrement-Felder sind immer Integer-Felder.

Aber nicht notwendigerweise vorzeichenbehaftet.

int unsigned ist durchaus möglich.
Dann wären natürlich negative Werte nicht möglich - daher auch meine Frage nach dem Typ.

Falls integer, könntest Du negative Werte für Deine Spezial-Datensätze benutzen.
Nein, das geht nicht. Jedenfalls nicht bei MySQL:

Ach? Komisch, daß ich das seit vielen Jahren erfolgreich für ähnliche Zwecke verwende.

Es mag sein, daß es nicht funktioniert, wenn die automatisch erzeugten Werte im negativen Bereich liegen sollen.
Aber von Hand vorgegebene Werte können auch in einer Spalte, deren Werte im Normalfall per auto_increment gesetzt werden, durchaus negativ sein.

Sag mal, geht es eigentlich noch billiger, Du Experte (siehe oben)? In zwei Sätzen hast Du mir zwei falsche Tipps gegeben.

So, hab ich das, Du Experte?

cu,
Andreas

[Markus]

Hallo Mudgard,

Aber nicht notwendigerweise vorzeichenbehaftet.

Stimmt, das war aber nicht Deine Frage: "Falls integer...". Natürlich Integer, was sonst.

Ach? Komisch, daß ich das seit vielen Jahren erfolgreich für ähnliche Zwecke verwende.

Ja, stimmt auch, habe es gerade ausprobiert. Da man aber nicht jeden Sonderfall und dessen Behandlung durch MySQL kennen kann, lese ich Handbücher etc. Und da steht der zitierte Satz, der - das ist richtig - nicht ganz eindeutig ist.

So, hab ich das, Du Experte?

Nein, hast Du nicht. Du bist mir aber vorsichtshalber noch die Antwort hierauf schuldig geblieben:

"Inwiefern war meine Frage denn bitte unberechtigt oder unprofessionell?"

Bin gespannt!
Grüße, Markus

[Ilja]

yo,

"Inwiefern war meine Frage denn bitte unberechtigt oder unprofessionell?"

ob es unprofessionell ist, sei mal dahingestellt. aber der tipp, einen primär-schlüssel nicht zu verändern hat durchaus einen guten grund. die aufgabe eines pk ist einen datensatz eindeutig zu identifizieren und das war es dann auch schon. was du machen willst, sind sogenannte sprechende schlüssel, sprich mit dem wert des schlüssels sind noch weitere Informationen (funktionen) versteckt. das hat man früher sehr oft gemacht, die erfahrung hat aber gezeigt, dass es zu problemen führen kann. wenn man es verhindern kann und das kann man sehr gut in deinem falle, dann sollte man den pk nicht mehr verändern und vor allem keine zusätzlichen infomationen dort reinstecken.

Ilja

[Markus]

Hallo Ilja

sind sogenannte sprechende schlüssel, sprich mit dem wert des schlüssels sind noch weitere Informationen (funktionen) versteckt.

Weitere Informationen ja, Funktionen nein. Ich möchte nur auf einen Blick und anhand der ID erkennen können, ob es ein Spezialaccount ist oder nicht, nichts weiter. Programmatisch werde ich diese nicht als "sprechende" Schlüssel verwenden, also keinerlei Logik darauf aufbauen.

Spricht sonst noch etwas dagegen?
Danke und Grüße,
Markus

[Ilja]

yo,

Weitere Informationen ja, Funktionen nein. Ich möchte nur auf einen Blick und anhand der ID erkennen können, ob es ein Spezialaccount ist oder nicht, nichts weiter. Programmatisch werde ich diese nicht als "sprechende" Schlüssel verwenden, also keinerlei Logik darauf aufbauen.

doch, informationen in einem schlüssel sind sprechende schlüssel, das steckt ja in dem namen " sprechen" drinne. du siehst einen pk und er spricht zu dir, ich bin ein spezial-account. wie gesagt, es ist dein projekt und deine entscheidung. allerdings würde ich die vorteile und die nachteile abwägen. eine zusätzliche spalte hat meiner meinung nach mehr vorteile als nachteile. der einzige nachteile wäre speicherplatz, aber das sollte doch nicht wirklich ein argument sein oder ?

Ilja

[wahsaga]

hi,

Weitere Informationen ja, Funktionen nein. Ich möchte nur auf einen Blick und anhand der ID erkennen können, ob es ein Spezialaccount ist oder nicht, nichts weiter. Programmatisch werde ich diese nicht als "sprechende" Schlüssel verwenden, also keinerlei Logik darauf aufbauen.

Gut, nehmen wir jetzt mal an, ein Admin soll irgendwann nicht mehr Admin sein - z.B., weil es dich nervt, von ihm immer in "sinnlose Meta-Diskussionen" verwickelt zu werden :-) - was machst du dann?
Wird dann der PK erneut verändert?

eine zusätzliche spalte hat meiner meinung nach mehr vorteile als nachteile.

Die hat er ja sowieso, wenn ich die weiteren Ausführungen jetzt richtig verstanden habe - der "sprechende" PK soll also über diese Kategorie des Datensatzes nur "schnelleren" Überblick bieten.
Darin sehe ich dann aber noch eine weitere Gefahrenstelle für die Datenkonsistenz bei Änderung.

gruß,
wahsaga

[Markus]

Hi, ich nehme an Du meintest mich jetzt mit Deiner Antwort?

Gut, nehmen wir jetzt mal an, ein Admin soll irgendwann nicht mehr Admin sein - z.B., weil es dich nervt, von ihm immer in "sinnlose Meta-Diskussionen" verwickelt zu werden :-) - was machst du dann?

Also um es nochmal zu verdeutlichen: ich habe bereits eine Spalte "admin" (Ja/Nein). Mein ganz persönlicher Account hat die ID 101 und admin auf "Ja" gesetzt. Der Spezialaccount "anonymous" hat (jetzt) die ID 1 und wird genutzt, um damit Kommentare zu verknüpfen, die halt Anonym geschrieben wurden, mal so als Beispiel.

Wird dann der PK erneut verändert?

Dieser Fall wird nicht vorkommen. Hinter den Spezialaccounts stecken keine Menschen, das ist ja das spezielle an ihnen.

Die hat er ja sowieso, wenn ich die weiteren Ausführungen jetzt richtig verstanden habe - der "sprechende" PK soll also über diese Kategorie des Datensatzes nur "schnelleren" Überblick bieten.

Also meinst Du doch Ilja. Egal, richtig das soll er.

Darin sehe ich dann aber noch eine weitere Gefahrenstelle für die Datenkonsistenz bei Änderung.

Auch für Dich nochmal, habe ich gerade schon wo anders gepostet:

http://www.niallkennedy.com/blog/uploads/flickr_php.pdf
http://www.kottke.org/04/10/normalized-data

• Normalised data is for sissies
• Keep multiple copies of data around
• Makes searching faster
• Have to ensure consistency in the application logic

Beachte die erste Aussage und beachte bitte, von welcher Anwendung (Flickr) wir hier reden. Das meine ich mit Pragmatismus. Und ja, ich dokumentiere meinen Kram, der Nächste wird sich also zurecht finden.

Beste Grüße,
Markus

[Ilja]

yo,

normalisierung ist ein anderes thema. der springende punkt von meiner seite aus ist, dass du keine vorteile dadurch hast, ID's einen besondere bedeutung zu geben. auszulesen, ob ein account einen bedeutung hat oder nicht, kann man auch ohne normalisierung auf eine ganz einfache art und weise lösen.

sprich, du hast keine vorteile und nur nachteile. ich halte das nicht für den richtigen weg, aber es ist halt deiner. oder fällt dir ein vorteil für sprechende schlüssel ein ?

Ilja

[Markus]

Yo Ilja :)

normalisierung ist ein anderes thema. der springende punkt von meiner seite aus ist, dass du keine vorteile dadurch hast, ID's einen besondere bedeutung zu geben. auszulesen, ob ein account einen bedeutung hat oder nicht, kann man auch ohne normalisierung auf eine ganz einfache art und weise lösen.

sprich, du hast keine vorteile und nur nachteile.

nimm es mir nicht übel aber Du hast mich noch nicht davon überzeugen können, dass ich überhaupt einen Nachteil dadurch habe. Welchen denn, wenn ich keinerlei Logik (das ist der springende Punkt) auf die implizite Semantik anwende sondern es aus rein, nennen wir es mal "optischen" Gründen so machen möchte? Ich möchte - und damit hat auch kein anderer Mit-Entwickler was zu tun - auf einen Blick sehen, was mir wichtig ist. Dabei geht es um das sehen mit den "Augen", nicht mit meiner Software. Meiner Software ist's völlig schnuppe ab welchem Index die Spezial/Normal-Accounts zu finden sind und ich habe auch nicht vor das zu ändern.

oder fällt dir ein vorteil für sprechende schlüssel ein ?

Siehe oben. Ich glaube wir drehen uns jetzt im Kreise. Ich habe das Gefühl, ich schaffe ich es nicht ganz rüberzubringen, wozu die ganze Aktion gedient hat. Lassen wir es mal gut sein? Da geht soviel Zeit für eine eigentlich recht unwichtige Sache drauf, die ich ja auch schon längst gelöst und abgeschlossen habe.

Trotzdem danke für Deine Hilfe, Ilja!
Schönen Feierabend,
Markus

[Markus]

Hallo Ilja,

doch, informationen in einem schlüssel sind sprechende schlüssel, das steckt ja in dem namen " sprechen" drinne.

man kann es ja nennen, wie man möchte. So lange ich keine Logik darauf anwende, hat es keine einleuchtenden Nachteile. Eine zusätzliche Spalte macht deswegen auch keinen Sinn, weil ich diese nie per SQL-Query abfragen möchte. Der Vorteil meiner Vorgehensweise ist aber, daß ich in den Tabellen, die den Fremdschlüssel nutzen, auf einen Augenblick schon sehe, ob es ein Spezialaccount ist oder nicht. Das ginge mir verloren, wenn ich es über eine zusätzliche Spalte löse und dann erstmal mühsam JOINen muß.

der einzige nachteile wäre speicherplatz, aber das sollte doch nicht wirklich ein argument sein oder ?

Nein, da hast Du recht. Mir geht es auch nicht um Speicherplatz sondern schlicht um Übersicht bei der tagtäglichen Administration.

Am Rande: Normalisierung der Normalisierung wegen ist nicht sinnvoll. Ich erinnere mich an einen Artikel, in dem ein Google-Mitarbeiter deren Datenbanksystem erläuterte, in dem Daten eben nicht normalisiert abgelegt werden, sondern - aus Performance-Gründen - auch doppelt und dreifach. Da verlagert man Logik eben in eine andere Schicht und muss Sorge tragen, dass es sauber programmiert wird, gewinnt dabei auch enorm an Performance.

Da kann man jetzt Glaubenskriege drüber aufführen, ein Richtig oder Falsch gibt es so einfach aber nunmal nicht :)

Viele Grüße,
Markus

[wahsaga]

hi,

So lange ich keine Logik darauf anwende, hat es keine einleuchtenden Nachteile. Eine zusätzliche Spalte macht deswegen auch keinen Sinn, weil ich diese nie per SQL-Query abfragen möchte. Der Vorteil meiner Vorgehensweise ist aber, daß ich in den Tabellen, die den Fremdschlüssel nutzen, auf einen Augenblick schon sehe, ob es ein Spezialaccount ist oder nicht.

Wenn die Information, "Datensatz XY wurde von einem Spezial-Account angelegt" derart unwichtig ist - gerade dann verstehe ich nicht, warum sie auf diese Weise "auf den ersten Blick verfügbar" sein soll.

Was ist denn, wenn Spezial-Account #67 irgendwann mal keiner mehr sein soll - dann würdest du ihn ja, wenn ich dich richtig verstanden habe, "nach oben shiften", sagen wir auf #133.

Jetzt ist an deinem Datensatz gar nicht mehr erkennbar, dass er irgendwann mal von einem Spezial-Account angelegt wurde - er sieht jetzt so aus, als ob er schon von vornherein von einem "Normalo" angelegt gewesen wäre - ist das beabsichtigt?

gruß,
wahsaga

[Markus]

Wenn die Information, "Datensatz XY wurde von einem Spezial-Account angelegt"

Ich präzisiere nochmal: nicht "von einem Account angelegt" sondern "mit einem Account verknüpft wird". Das hat eine etwas andere Qualität und hat unter anderem Auswirkungen auf:

Was ist denn, wenn Spezial-Account #67 irgendwann mal keiner mehr sein soll - dann würdest du ihn ja, wenn ich dich richtig verstanden habe, "nach oben shiften", sagen wir auf #133.

Grüße, Markus

[Alexander Brock]

Hallo Freunde des gehobenen Forumsgenusses,

Der Vorteil meiner Vorgehensweise ist aber, daß ich in den Tabellen, die den Fremdschlüssel nutzen, auf einen Augenblick schon sehe, ob es ein Spezialaccount ist oder nicht. Das ginge mir verloren, wenn ich es über eine zusätzliche Spalte löse und dann erstmal mühsam JOINen muß.

Ich habe dich bereits auf enum hingewiesen, also komm nicht damit dass Joins mühsam sind, man braucht keinen Join, nur ein Feld.

Dieses Feld anzugucken halte ich auch für wesentlich einfacher als zu sehen, ob eine ID größer oder kleiner n ist.

Gruß
Alexander Brock

[Markus]

Dieses Feld anzugucken halte ich auch für wesentlich einfacher als zu sehen, ob eine ID größer oder kleiner n ist.

Du hast offensichtlich nicht begriffen, was ich erreichen wollte. Wie deutlich soll man es noch ausdrücken? Wenn ich in eine Tabelle "comments" reingucke, steht dort nur der Fremdschlüssel account_id, NICHT das enum-Feld. Um an das enum-Feld zu kommen und somit zu erkennen, dass es sich um einen Spezialaccount handelt MUSS ich einen JOIN machen. Wenn Du nur weiter stänkern und Recht behalten bist, vergeude halt Deine und meine Zeit.

Und das affige "lebe halt damit" kannst Du Dir auch sparen.

Gruß, Markus

[Hans]

Hi Markus,

warum machst Du es nicht so:

ID      JOB       Name
---------------------------------
1        0        Hans
2        1        Markus
3        1        Hinz
4        1        Kunz

Und in einer weiteren Tabelle:

JOB          Bezeichnung
--------------------------------
0            Admin
1            normaler user

Dann kannst Du, unabhängig von der ID für alle admins machen:

update tabelle set spalte=neuer_wert where JOB=0;

Gruß

Hans

[Markus]

Hallo Hans,

update tabelle set spalte=neuer_wert where JOB=0;

ja, das wäre theoretisch möglich. Ich finde die von mir angestrebte Lösung aber eleganter, da ich sonst für tausende von Zeilen ein Feld mitführen muss, obwohl das nicht notwendig ist. Zumal ich die Abfrage nach Spezialaccounts nur selten durchführen muss.

Ich habe es jetzt einfach programmatisch gelöst:

Erst:
SELECT id FROM account ORDER BY id DESC

Dann loope ich durch das Ergebnis und führe für jede Zeile:
UPDATE account SET id = id + 1 WHERE id = $id

durch. Durch die Sortierung der Zeilen fange ich von hinten an und es kommt zu keiner Kollision mit bereits vergebenen IDs.

Muss ja nur ein einziges Mal gemacht werden, da ist's nicht so schlimm, wenn ich da viele Queries lostreten muss.

Trotzdem herzlichen Dank für Deinen Lösungsvorschlag!
Markus

[wahsaga]

hi,

ja, das wäre theoretisch möglich. Ich finde die von mir angestrebte Lösung aber eleganter,

Ist sie aber nicht.

da ich sonst für tausende von Zeilen ein Feld mitführen muss, obwohl das nicht notwendig ist.

Dafür willst du jetzt _Inhalt_ in einem Feld ablegen, welches diese Aufgabe absolut nicht zu übernehmen hat.

Ja, vernünftig normalisieren mag ab und zu nach Overhead aussehen.

ich möchte für Spezialaccounts (admin, anonymous usw.) einen Bereich im Range von 1-100 reservieren.

Aber wenn dann irgendwann die Anzahl solcher "Spezialaccounts" mal die 100 übersteigen sollte - was machst du dann?

gruß,
wahsaga

[Markus]

Hello wahsaga,

ja, das wäre theoretisch möglich. Ich finde die von mir angestrebte Lösung aber eleganter,

Ist sie aber nicht.

Begründe das bitte. Ist sie aber DOCH! So ungefähr könnte man die Diskussion hier weiterführen.

Dafür willst du jetzt _Inhalt_ in einem Feld ablegen, welches diese Aufgabe absolut nicht zu übernehmen hat.

Ich werde keine Logik auf diese ersten 100 Datensätze abbilden, sie sollen mir selbst bei manchen administrativen Aufgaben helfen, den Überblick zu behalten, da ich zum Beispiel auf _einen_ Blick sehe, das ein Datensatz in der Tabelle "comments" (mit Verknüpfung zur account-Tabelle) von einem Spezialaccount stammt. Diese Lösung ist elegant und sinnvoll. Mit der normalisierten Lösung wäre das nicht möglich, ohne Zugriff auf die account-Tabelle.

Ja, vernünftig normalisieren mag ab und zu nach Overhead aussehen.

Ich habe noch die Worte meines Datenbank-Profs im Ohr, der nichts von unbedingter Normalisierung hielt. Aufwachen, es geht um reale Problematiken und pragmatische Lösungen.

Aber wenn dann irgendwann die Anzahl solcher "Spezialaccounts" mal die 100 übersteigen sollte - was machst du dann?

Mach Dir mal nicht meinen Kopf. Bisher gibt es derer 2 und es ist unwahrscheinlich, dass es mal mehr werden. Und wenn, dann kann ich mein Script nochmal anwenden und nochmal 100 freischaufeln.

Es nervt irgendwie, solche Metadiskussionen zu führen, in denen man gefragt wird, warum man den dies und jenes tun möchte. Vielleicht solltest Du mal versuchen die Menschen, die hier um Hilfe ersuchen zunächst mal ernst zu nehmen, bevor Du (dankenswerterweise!) Deine Hand reichst. Das ist hier keine Lehrer-Schüler-Situation sondern (hoffentlich) ein Forum in dem man auf Augenhöhe diskutiert und einer dem anderen hilft. Auch ich tue das übrigens gelegentlich, unter Pseudonym und ohne Allüren, nicht nur im Selfforum.

Nichts für Ungut + Grüße,
Markus

[Alexander Brock]

Hallo Freunde des gehobenen Forumsgenusses,

Ist sie aber nicht.

Begründe das bitte. Ist sie aber DOCH! So ungefähr könnte man die Diskussion hier weiterführen.

Hat er doch im weiteren Verlauf des Postings, du gehst auch auf seine Argumente ein, also warum unterstellst du eine fehlende Begründung?

Dafür willst du jetzt _Inhalt_ in einem Feld ablegen, welches diese Aufgabe absolut nicht zu übernehmen hat.

Ich werde keine Logik auf diese ersten 100 Datensätze abbilden, sie sollen mir selbst bei manchen administrativen Aufgaben helfen, den Überblick zu behalten, da ich zum Beispiel auf _einen_ Blick sehe, das ein Datensatz in der Tabelle "comments" (mit Verknüpfung zur account-Tabelle) von einem Spezialaccount stammt. Diese Lösung ist elegant und sinnvoll. Mit der normalisierten Lösung wäre das nicht möglich, ohne Zugriff auf die account-Tabelle.

Wenn du genau weist, dass es nur zwei Typen von Benutzern gibt kannst du dir die IDs auch merken, oder du könntest anstelle der ID so ein Feld machen:

account enum("special", "normal"),

Ja, vernünftig normalisieren mag ab und zu nach Overhead aussehen.

Ich habe noch die Worte meines Datenbank-Profs im Ohr, der nichts von unbedingter Normalisierung hielt. Aufwachen, es geht um reale Problematiken und pragmatische Lösungen.

Vollständig normalisieren kann sinnvoll sein (hab ich auch schon gemacht).

Aber wenn dann irgendwann die Anzahl solcher "Spezialaccounts" mal die 100 übersteigen sollte - was machst du dann?

Mach Dir mal nicht meinen Kopf. Bisher gibt es derer 2 und es ist unwahrscheinlich, dass es mal mehr werden. Und wenn, dann kann ich mein Script nochmal anwenden und nochmal 100 freischaufeln.

Wenn du korrekt normalisieren würdest (oder die enum-Lösung) könnte die gesamte Menschheit Admin sein ohne dass du alle 100 Benutzer irgendetwas machen müsstest (außer mehr Rechenzeit kaufen).

Es nervt irgendwie, solche Metadiskussionen zu führen, in denen man gefragt wird, warum man den dies und jenes tun möchte.

Nur so kann man von anderen lernen, wenn du immer nur wissen willst wie du dein Konzept am besten umsetzt kannst du nicht lernen, bessere Konzepte zu erstellen.

Zum Glück gibt es hier Leute, die automatisch dein Konzept hinterfragen und Schwachstellen kritisieren, was du dann dann daraus machst ist deine Sache.

Wer aufgehört hat zu versuchen besser zu sein hat aufgehört gut zu sein.

Gruß
Alexander Brock

[Ilja]

yo,

Wer aufgehört hat zu versuchen besser zu sein hat aufgehört gut zu sein.

wobei nicht jeder der gut ist auch glücklich ist. oder mit anderem worten, man muss nicht gut sein, um glücklich zu sein.

Ilja

[Markus]

Zum Glück gibt es hier Leute, die automatisch dein Konzept hinterfragen und Schwachstellen kritisieren, was du dann dann daraus machst ist deine Sache.

Wer aufgehört hat zu versuchen besser zu sein hat aufgehört gut zu sein.

Ich sehe Deine Argumente, sie treffen auf den aktuellen Fall aber nicht zu. Normalisierung ist eben NICHT der Weisheit letzter Schluss, wie ich hier im Thread auch schon mehrfach angeführt habe. Wenn Du mir nicht glaubst, dann vielleicht dem Technologie-Chef von Flickr:

http://www.niallkennedy.com/blog/uploads/flickr_php.pdf
http://www.kottke.org/04/10/normalized-data

• Normalised data is for sissies
• Keep multiple copies of data around
• Makes searching faster
• Have to ensure consistency in the application logic

Wie ich schon schrieb, es geht um reale Projekte und pragmatische Lösungen.

Beste Grüße,
Markus

[Markus]

Hallo Alexander,

Nur so kann man von anderen lernen, wenn du immer nur wissen willst wie du dein Konzept am besten umsetzt kannst du nicht lernen, bessere Konzepte zu erstellen.

dazu noch ein Wort, mir fiel gerade ein - naja, halb-gutes - Gleichnis ein: ich komme zu SelfHTML zum Fragen oft nur vorbei, wenn ich ein ganz spezielles Problem habe, dem ich vorher schon 1-2 Stunden hinterher recherchiert habe. Meist habe ich vorher noch mit Freunden telefoniert und das Thema auch mit denen kurz bequatscht. Zum Hintergrund, nicht ganz unwichtig: ich bin Diplom-Informatiker und seit 11 Jahren berufstätig. Das schützt mich zwar nicht vor Torheiten, aber es gibt gewisse Sachverhalte, über die habe ich lange und oft nachgedacht und habe eine Entscheidung getroffen, zum Beispiel dass ich de-Normalisierung dann anwende, wenn ich einen gewissen Bedarfsfall habe, der überschaubar komplex ist und von dem ich denke, dass ich diesen über die Applikationslogik im Griff habe oder wenn Daten nicht 100% sicher sein müssen, ich baue schliesslich keine Bankensoftware. Diese Entscheidung muss zwar auch nicht dauerhaft sein, jedoch hilft es mir eben nicht, diese in einem Moment, in dem ich ein ganz anderes Problem habe, mit 3,4,5 anderen zu diskutieren sondern lenkt mich von meinem Problem ab. Habe heute miindestens 2 Stunden in diesem Thread verbracht, die Lösung habe ich selbst gefunden, nachdem mir das zu "blöd" wurde.

Um eine Analogie zu finden: ich möchte zum Bahnhof laufen weil das Wetter so schön ist, frage jemanden nach dem Weg und er sagt mir: "das ist zu weit weg um zu Fuß zu gehen, nehmen Sie lieber den Bus." Ich bedanke mich, verneine das jedoch und bitte nochmals um einen Wink nach dem Weg. Und jetzt versucht dieser durchaus nette und hilfsbereite Mensch mich zu überzeugen und hält mich dabei mehr auf, als er mir weiterhilft. Ich unterstelle diesem Jemand nicht, dass er mir schaden möchte, ganz im Gegenteil. Er tut es aber de-facto doch.

So etwas passiert im normalen Leben natürlich nicht. Warum dann in Foren oder Mailinglisten? Ich akzeptiere mittlerweile, dass das so ist, hilfreich ist es dann aber nur manchmal. Ich denke einfach, man sollte die Menschen, die einen etwas Fragen nicht lehrerhaft betrachten sondern auf Augenhöhe, das wollte ich vorhin auch ausdrücken.

Nur so ein paar Gedanken zum Thema, ich habe jetzt auch keine Zeit mehr das weiter zu verfolgen.

Beste Grüße,
Markus

[Struppi]

So etwas passiert im normalen Leben natürlich nicht. Warum dann in Foren oder Mailinglisten? Ich akzeptiere mittlerweile, dass das so ist, hilfreich ist es dann aber nur manchmal. Ich denke einfach, man sollte die Menschen, die einen etwas Fragen nicht lehrerhaft betrachten sondern auf Augenhöhe, das wollte ich vorhin auch ausdrücken.

Woher soll dein Gegenüber im Forum Wissen auf welcher Höhe du bist?
Aus dem https://forum.selfhtml.org/?t=130804&m=845831 Posting geht das nicht hervor.

Insofern ist es nicht verwunderlich, dass Fragen, die für einen selbst, schlüssig klingen, für Aussenstehende, die auf deine knappen Schilderungen angewiesen waren, auch nach einer Dummheit klingen können.
Du hast ja erst, Schrittweise, im Laufe der Diskussion, sowohl deinen Wissenstand, als auch deine konkrete Zielsetzung, Preis gegeben. Und wie du selbst zugibst, hat dich das einiges an Kopfzerbrechen gekostet. Du erwartest einiges an unreflektiertheit von den Leuten die helfen wollen, die es so nicht geben kann.

Das Interessante an der Diskussion war, dass gerade Ilja eigentlich einer ist, der hier immer wieder propagiert, dass man als Antwortender einfach helfen soll, nur es ist eben nicht so einfach, wie es für einen selbst erstmal erscheint und deshalb sind kritische Fragen nach dem Sinn völlig normal und oft auch nützlich (auch wenn es in deinem Fall nicht so war)

Struppi.

[Markus]

Woher soll dein Gegenüber im Forum Wissen auf welcher Höhe du bist?
Aus dem https://forum.selfhtml.org/?t=130804&m=845831 Posting geht das nicht hervor.

Das ist doch meine Rede: ich stelle eine Frage und entweder möchte man mir die beantworten oder eben eine Meta-Diskussion anfangen. Wenn ich helfe, dann tue ich das zunächst ohne dem anderen meine Sichtweise aufdrücken zu wollen bzw. noch ne abfällige Bemerkung bezüglich dessen Kenntnisse loszulassen wie das hier einige versucht haben (wahsaga, Mudgard & co.).

Wenn der Frager dann nicht zurecht kommt, wird er eben nochmal nachfragen.

deine knappen Schilderungen angewiesen waren

Die Frage auf die ich um Hilfe ersucht habe war eindeutig und ausreichend beschrieben: Wie kriege ich es hin die IDs eines autoincrement-Feldes um einen Index hochzusetzen. Ich hatte sogar beschrieben, aus welchem Grund es mit meinem ersten Ansatz nicht hingehauen hat. Was fehlte denn da bitte, um kurz und knapp Hilfestellung zu leisten, genau so wie das u.a. Rouven später getan hat?

Sicher: ich habe nicht gefragt, ob es bessere Lösungsansatz gäbe, weil ich mir schon selbst meine Gedanken dazu gemacht und das für sinnvoll befunden habe. Und deswegen habe ich auch nicht dargestellt, _warum_ ich das machen möchte, das tut doch gar nichts zur Sache. Aber genau auf diese nicht gestellte Frage haben dann einige Teilnehmer geantwortet und die Diskussion unsinnigerweise in die Länge gezogen und somit niemandem gedient. Weder mir noch sich selbst, weil sich meine Dankbarkeit dann auch in Grenzen hält. Aber am Ende sind alle angpisst und haben Zeit verschleudert.

Hätte man mich und meine Frage für voll genommen, wäre vielleicht in Minuten ein Ergebnis rumgekommen. Und Du willst mir jetzt nicht ernsthaft vorschlagen, dass ich am Anfang einer jeden Fragestellung offenbare, dass ich Informatiker bin und man mich bitte dem Wissensstand entsprechend behandeln soll ;-)

Ich habe aber wohl eine andere Philosophie, was Foren und den Umgang mit ihnen angeht. Wir sind alles Leute mit wenig Zeit und viel Arbeit und deswegen sollten Fragen mit den notwendigsten Informationen versehen werden und notfalls iterativ an ein Ergebnis rangetastet werden statt dass ich eine zweiseite Fragestellung formuliere, in dem ich den Gesamtkomplex darstelle und mich dann im Kreuzverhör befinde, warum ich es denn so und nicht anders löse, warum ich denn nicht PostgreSQL statt MySQL verwende usw. (ich überspitze) und die eigentliche Fragestellung die eine ganz spezielle war, in den Hintergund gerät.

Grüße, Markus

[Alexander Brock]

Hallo Freunde des gehobenen Forumsgenusses,

Um eine Analogie zu finden: ich möchte zum Bahnhof laufen weil das Wetter so schön ist, frage jemanden nach dem Weg und er sagt mir: "das ist zu weit weg um zu Fuß zu gehen, nehmen Sie lieber den Bus." Ich bedanke mich, verneine das jedoch und bitte nochmals um einen Wink nach dem Weg. Und jetzt versucht dieser durchaus nette und hilfsbereite Mensch mich zu überzeugen und hält mich dabei mehr auf, als er mir weiterhilft. Ich unterstelle diesem Jemand nicht, dass er mir schaden möchte, ganz im Gegenteil. Er tut es aber de-facto doch.

"Entschuldigen Sie, könnten Sie mir erklären, an welcher Stelle ich am besten die Fassade des Fernsehturms hochklettere?"

"Warum nehmen Sie nicht den Fahrstuhl wie jeder normale Mensch? Das ist doch viel bequemer und sicherer!"

"Nein, ich will jetzt die Fassade am Efeu hochklettern weil ich zu lange auf den Fahrstuhl warten muss und Alexander Huber würde das auch so machen"

Aber wie gesagt, es ist deine Entscheidung und du wirst mit ihr leben müssen.

Gruß
Alexander Brock

[wahsaga]

hi,

Ich finde die von mir angestrebte Lösung aber eleganter,

Ist sie aber nicht.

Begründe das bitte.

Was es da zu begründen gibt, sagte ich bereits:

Du bringst eine Eigenschaft des Datensatzes an einer Stelle unter, wo das bei Betrachtung des Datenmodells absolut nicht ersichtlich ist.

Ist sie aber DOCH! So ungefähr könnte man die Diskussion hier weiterführen.

Nur, wenn du dich kindisch benehmen, und vernünftige Argumente nicht anerkennen magst.

Ich werde keine Logik auf diese ersten 100 Datensätze abbilden, sie sollen mir selbst bei manchen administrativen Aufgaben helfen, den Überblick zu behalten, da ich zum Beispiel auf _einen_ Blick sehe, das ein Datensatz in der Tabelle "comments" (mit Verknüpfung zur account-Tabelle) von einem Spezialaccount stammt.

Dass erkennst du, weil du dich erinnerst, dass du auf diese verquere Weise ein Attribut an dieser Stelle "abgelegt" hast - erkennt das ein anderer, der vielleicht mal mit deinem System arbeiten muss, auch? Erkennt er es auch, wenn er sich lediglich dein Datenmodell ansieht, ohne verbale Erklärungen dazu zur Hand zu haben, in denen du dein "unorthodoxes" Vorgehen noch mal beschreibst?

Und du erkennst es _noch_ - in einem Jahr, in fünf Jahren auch noch?

Diese Lösung ist elegant und sinnvoll.

Daran kann ich, wie gesagt, absolut nichts elegantes finden.
Du hast in deinem Supermarktregal von allen Konservendosen die Etiketten abgelöst - wo jetzt Erbsensuppe drin ist, erkennt man nur noch daran, dass diese Dosen in einer bestimmten Ecke stehen.
Wenn ich jetzt eine Dose nehme, und woanders hinstelle, kann kein Mensch mehr ohne sie zu öffnen sagen, was drin ist.

Mit der normalisierten Lösung wäre das nicht möglich, ohne Zugriff auf die account-Tabelle.

Diesen bei Bedarf herzustellen, sollte deine Applikation übernehmen.

Ich habe noch die Worte meines Datenbank-Profs im Ohr, der nichts von unbedingter Normalisierung hielt. Aufwachen, es geht um reale Problematiken und pragmatische Lösungen.

Ach ja, "pragmatisch" - das wird doch nur zu gerne verwendet, um suboptimale "Lösungen" als bestmögliche zu Verkaufen, auf wenn sie das bei objektiver Betrachtung keineswegs sind.

Aber wenn dann irgendwann die Anzahl solcher "Spezialaccounts" mal die 100 übersteigen sollte - was machst du dann?

Mach Dir mal nicht meinen Kopf. Bisher gibt es derer 2 und es ist unwahrscheinlich, dass es mal mehr werden.

Wenn du dir diesen Kopf schon nicht "machst" - obwohl du das solltest, wenn du eine vernünftig skalier- und erweiterbare Applikation aufbauen willst - dann muss es ja jemand anderes übernehmen.

Und wenn, dann kann ich mein Script nochmal anwenden und nochmal 100 freischaufeln.

Durch fröhliches weiteres Verändern der ID in solchen Fällen, wo dein Aufbau dies "brauchen" würde, nimmst du ihr ihre eigentliche Funktionalität - eindeutiges Identifizieren eines Datensatzes - also ganz nach belieben noch mehr.

Es nervt irgendwie, solche Metadiskussionen zu führen, in denen man gefragt wird, warum man den dies und jenes tun möchte.

Das hier gerne geübte kritische Hinterfragen von Vorgehensweisen kann sehr oft vor Denkfehlern bewahren - und m.E. machst du gerade einen kapitalen solchen.

gruß,
wahsaga

[Rouven]

Hi,

davon abgesehen, dass ich dein Vorhaben auch für extrem unklug halte, soll mich das noch nicht davon abhalten Hilfestellung zu geben (na ja, zumindest ein Versuch).

Wenn an deinem Primary Key nichts dranhängt könntest du mal versuchen das Constraint zu droppen, weiß allerdings nicht, ob MySQL das mitmacht. Also nach dem Motto weg mit dem Schlüssel, das Update was du versucht hast, Schlüssel wieder hin.

MfG
Rouven

[Rouven]

Hmpf, ich setz noch einen drauf - mach den Umweg über eine temporäre Tabelle, klappt auf jeden Fall (Syntax mag etwas durch den Wind sein...):

INSERT INTO zwischentab (id, ...)
SELECT id+1, ...
FROM tab;

DELETE FROM tab;

INSERT INTO tab
SELECT ... FROM zwischentab;

MfG
Rouven

[Markus]

Hallo Rouven,

vielen Dank!

Hmpf, ich setz noch einen drauf - mach den Umweg über eine temporäre Tabelle, klappt auf jeden Fall (Syntax mag etwas durch den Wind sein...):

Ich habe es jetzt allerdings bereits so gelöst:

https://forum.selfhtml.org/?t=130804&m=845862

Danke nochmal und einen schönen Feierabend,
Markus