primärschlüssel "resetten"??

[bleicher]

Шалом ,друзі!

ich bin es wieder mal ^^ mit noch einer "was tut man , wenn die Maus den Mauspadrand erreicht hat , aber der Mauszeiger noch nicht am Bildschirmrand ist?" -Frage.

Und zwar: ich habe eine SQL tabele in der eien Spalte (id) mit Primarschlüssel und auto_increment versehen ist. Das Problem - wird eine Zeile (zB mit id 5) gelöscht und eine neue hinzugefügt kriegt die neue #6 , auto_increment zählt also weiter ob die vorherige zeile da ist oder nicht.

Die Frage - wie kann ich erreichen , daß die Zeilen eine "ordentliche" Nummerierung kriegen?

[Vinzenz Mai]

Hallo

Und zwar: ich habe eine SQL tabele in der eien Spalte (id) mit Primarschlüssel und auto_increment versehen ist. Das Problem - wird eine Zeile (zB mit id 5) gelöscht und eine neue hinzugefügt kriegt die neue #6 , auto_increment zählt also weiter ob die vorherige zeile da ist oder nicht.

das ist in Ordnung so.

Die Frage - wie kann ich erreichen , daß die Zeilen eine "ordentliche" Nummerierung kriegen?

Das hast Du doch schon. Wo ist Dein Problem? Die Lücken? Die sind kein Problem, das ist in Ordnung. Das ist gut und richtig so. Es soll auch gar nicht anders sein.

Wenn Du Deine Datensätze durchnumerieren möchtest, so solltest Du zunächst wissen, dass die Datensätze in einer Datenbank nicht geordnet vorliegen (müssen). Wenn Du eine Ordnung hineinbringen willst, so nutzt Du die ORDER BY-Klausel der SELECT-Anweisung. Wie Du Deine Datensätze durchnumerieren kannst, das hängt von Deinem Datenbankmanagementsystem, ggf. auch der Version ab.

ids sind dafür da, einen Datensatz zu _id_entifizieren - und nicht um irgendeine Ordnung in das System zu bringen.

Freundliche Grüße

Vinzenz

[bleicher]

Danke ^^
das mit id ist ja sinnvoll...aber wenn man zB bilder in einer gallery mit "lücken" nummeriert wirkt es "seltsam".. ist denn "mysql_num_rows+1" & "nummerspalte" die einzige Möglichkeit??

danke^^

[Vinzenz Mai]

Hallo bleicher,

Danke ^^

Deine überflüssigen Zirkumflexe und Deine seltsame Interpunktion machen Deine Postings immer noch unnötig schwer lesbar :-(

das mit id ist ja sinnvoll...aber wenn man zB bilder in einer gallery mit "lücken" nummeriert wirkt es "seltsam".. ist denn "mysql_num_rows+1" & "nummerspalte" die einzige Möglichkeit??

Was meinst Du damit? Ich verstehe nur Bahnhof.
Da Du offensichtlich MySQL verwendest, könntest Du mit Benutzervariablen arbeiten.

SET @a = 0;  
SELECT  
    @a := (@a + 1) zaehler,  
    <Liste der sonstigen Spalten>  
FROM <Name Deiner Tabelle>  
ORDER BY <Liste der geeigneten Spalten>

sollte es tun. Da Du mit den alten MySQL-Funktionen von PHP arbeitest, musst Du die beiden Statements separat, aber in der gleichen Verbindung absetzen. Übrigens könntest Du zu diesem Thema im Archiv unter anderem diesen Beitrag von dedlfix finden.

Freundliche Grüße

Vinzenz

[bleicher]

Hallo bleicher,

Danke ^^

Deine überflüssigen Zirkumflexe und Deine seltsame Interpunktion »»machen Deine Postings immer noch unnötig schwer lesbar :-(

es sind smiles ^^ <- ^_^

->danke für den Rat - die Technik werde ich mir (früher oder später) aneignen , bis dato werde ich wohl doch auf die betagte numrows setzen

THX2ALL

[silver Karnickel]

Hi,

das mit id ist ja sinnvoll...aber wenn man zB bilder in einer gallery mit "lücken" nummeriert wirkt es "seltsam".. ist denn "mysql_num_rows+1" & "nummerspalte" die einzige Möglichkeit??

Was meinst Du damit? Ich verstehe nur Bahnhof.

klingeklingeling.

Eine so genannte benutzerfreundliche ID ist angefordert.

Das ist nicht ungewöhnlich. Das Gegenargument, dass man dann zwei Identifikationssysteme hätte, darf mit einem "Na und?" beantwortet werden.

Bzgl. der Lücken bei der technischen ID hast Du natürlich recht. Die benutzerfreundliche ID ist wohl nur unter Zuhilfenahme von Transaktionen zu erreichen. (Das dürfen auch hausgemachte sein, da muss der Datenserver nicht mitmachen, wenn er nicht kann (oder will).)

silver Karnickel

[Vinzenz Mai]

Hallo

das mit id ist ja sinnvoll...aber wenn man zB bilder in einer gallery mit "lücken" nummeriert wirkt es "seltsam".. ist denn "mysql_num_rows+1" & "nummerspalte" die einzige Möglichkeit??

Was meinst Du damit? Ich verstehe nur Bahnhof.

klingeklingeling.

Nein, es klingelt immer noch nicht. Es fällt kein Groschen. Nein. Ich verstehe den Satz nicht. Ich verstehe genau genommen den letzten "Satz" nicht. Immer noch nicht.

Eine so genannte benutzerfreundliche ID ist angefordert.

Was meinst Du, was bei meinem Codevorschlag in der Spalte zaehler steht? Ganz genau das: irgendeine "benutzerfreundliche" Zahl :-)

Das ist nicht ungewöhnlich. Das Gegenargument, dass man dann zwei Identifikationssysteme hätte, darf mit einem "Na und?" beantwortet werden.

Bzgl. der Lücken bei der technischen ID hast Du natürlich recht. Die benutzerfreundliche ID ist wohl nur unter Zuhilfenahme von Transaktionen zu erreichen. (Das dürfen auch hausgemachte sein, da muss der Datenserver nicht mitmachen, wenn er nicht kann (oder will).)

Nein, das verstehe ich nicht. Unabhängig davon, ob die Galerieseite zur Laufzeit generiert wird oder ein Caching-Mechanismus greift, sollte mein Vorschlag für MySQL (das ja hier im Einsatz ist) völlig ausreichend sein.

Beispiel:

mysql> set @a = 0;
Query OK, 0 rows affected (0.00 sec)

mysql> ~~~sql SELECT
    -> @a := (@a + 1) zaehler,
    -> id,
    -> landkreis
    -> FROM landkreise
    -> ORDER BY landkreis;

+---------+----+---------------------------+  
| zaehler | id | landkreis                 |  
+---------+----+---------------------------+  
|       1 |  5 | Landkreis Merzig-Wadern   |  
|       2 |  2 | Landkreis Neunkirchen     |  
|       3 |  4 | Landkreis Saarlouis       |  
|       4 |  6 | Landkreis St. Wendel      |  
|       5 |  3 | Saar-Pfalz-Kreis          |  
|       6 |  1 | Stadtverband Saarbrücken  |  
+---------+----+---------------------------+  
6 rows in set (0.00 sec)  
  
Getestet mit MySQL 4.1.15-nt. In meinen ids sind zwar keine Lücken, aber das Prinzip dürfte klar sein.  
  
  
Freundliche Grüße  
  
Vinzenz

[silver Karnickel]

Hi,

das mit id ist ja sinnvoll...aber wenn man zB bilder in einer gallery mit "lücken" nummeriert wirkt es "seltsam".. ist denn "mysql_num_rows+1" & "nummerspalte" die einzige Möglichkeit??

Was meinst Du damit? Ich verstehe nur Bahnhof.

klingeklingeling.

Nein, es klingelt immer noch nicht. Es fällt kein Groschen. Nein. Ich verstehe den Satz nicht. Ich verstehe genau genommen den letzten "Satz" nicht. Immer noch nicht.

nun, da fordert jemand ganz anscheinend Fotogalleryfotonamen mit Namensgebung a la "um eins hochzählende und Zahlenfolge mit dem vermuteten Startwert 1 (oder 0)". Der letzte Satz steht damit in einem Kontext, ergibt aber nur eingeschränkt einen Sinn, richtig. Aber man könnte dennoch mehr als "Bahnhof" verstehen, oder? :)

Eine so genannte benutzerfreundliche ID ist angefordert.

Was meinst Du, was bei meinem Codevorschlag in der Spalte zaehler steht? Ganz genau das: irgendeine "benutzerfreundliche" Zahl :-)

Fortlaufend (und permanent eindeutig? ;) muss die dann aber schon sein.

Nein, das verstehe ich nicht. Unabhängig davon, ob die Galerieseite zur Laufzeit generiert wird oder ein Caching-Mechanismus greift, sollte mein Vorschlag für MySQL (das ja hier im Einsatz ist) völlig ausreichend sein.

Deine benutzerfreundlichen IDs werden zur Laufzeit erstellt. Genau das ist oft nicht ausreichend. In unserem Fall? Tja, wenn der Patient schwierig ist und bspw. statische Verweise auf die netten Fotos irgendwo in seiner Website einbaut (ist ja nicht unwahrscheinlich - "ich würde es machen") oder wenn die Fotos gedownloadet werden, dann möchte man ja eigentlich schon Eindeutigkeiten.

Viele Grüße!
silver

[Vinzenz Mai]

Hallo

das mit id ist ja sinnvoll...aber wenn man zB bilder in einer gallery mit "lücken" nummeriert wirkt es "seltsam".. ist denn "mysql_num_rows+1" & "nummerspalte" die einzige Möglichkeit??

nun, da fordert jemand ganz anscheinend Fotogalleryfotonamen mit Namensgebung a la "um eins hochzählende und Zahlenfolge mit dem vermuteten Startwert 1 (oder 0)".

dieser Zusammenhang entgeht mir. Was hat eine Numerierung mit Namen zu tun? Wo wurde darauf auch nur angespielt?

Der letzte Satz steht damit in einem Kontext, ergibt aber nur eingeschränkt einen Sinn, richtig. Aber man könnte dennoch mehr als "Bahnhof" verstehen, oder? :)

Ich verstehe Deine Auslegung, kann diese beim besten Willen nicht in jenem für mich schwer zu lesenden Absatz wiederfinden :-) Wenn der OP dies meinte, dann hat er dies meiner Meinung nach sehr unglücklich formuliert.

Ja, das Problem einigermaßen genau zu beschreiben - und sich nicht in irgendwelchen Symptomen zu verheddern - das ist der beste Weg, sogar selbst eine Lösung zu finden.

Nein, ich bemühe mich schon, zwischen den Zeilen zu lesen - und bestehe nicht auf der Auslegung exakt nach dem Wort.

Nein, das verstehe ich nicht. Unabhängig davon, ob die Galerieseite zur Laufzeit generiert wird oder ein Caching-Mechanismus greift, sollte mein Vorschlag für MySQL (das ja hier im Einsatz ist) völlig ausreichend sein.

Deine benutzerfreundlichen IDs werden zur Laufzeit erstellt.

Zur Laufzeit des Skriptes. Dies kann einmalig sein, dies kann zu verschiedenen Zeitpunkten der Fall sein, je nach Bedarf.

Genau das ist oft nicht ausreichend. In unserem Fall? Tja, wenn der Patient schwierig ist und bspw. statische Verweise auf die netten Fotos irgendwo in seiner Website einbaut (ist ja nicht unwahrscheinlich - "ich würde es machen") oder wenn die Fotos gedownloadet werden, dann möchte man ja eigentlich schon Eindeutigkeiten.

Wenn es darum gehen sollte, den neuen Namen für das neue Bild zu finden, dann muss die Anwendungslogik verschiedene Fälle betrachten, die im Ausgangsposting nicht erwähnt sind:

Einfügen, die leichte Operation:
Einfügen ist selbstverständlich nur am "Ende" möglich. Soll nur ein neues Bild in die Galerie eingefügt werden, so ist es natürlich Unsinn, Daten aller relevanten Datensätze abzufragen, eventuell sogar bequem mit SELECT * FROM ..., die Daten anzufordern - und wegzuwerfen. Für soetwas gibt es COUNT().

Löschen, die schwierige Operation:
Ist es möglich, ein Bild zu löschen. Wenn ja, müssen innerhalb einer Galerie die Bilder umbenannt werden. Dazu wäre mein Statement als Ansatz brauchbar. Wie Rouven bereits schrieb, wären in einem solchen Fall Trigger durchaus nett. Ich weiß allerdings nicht, wie man die Race Condition zwischen Umbenennen der Dateien, Ändern der Links und Ändern in der Datenbank vermeiden kann. Man könnte sie als unvermeidbar für einen sehr kurzen Zeitraum hinnehmen. Mein Schluss lautete im Anwendungsfall jedoch: verzichte auf das Umbenennen, akzeptiere dass generierte Namen "Lücken" aufweisen.
Die Alternative: Bilder werden nicht gelöscht.

Ich persönlich finde nicht, dass durchnumerierte Bilder wirklich benutzerfreundliche Namen tragen. Meine persönliche Ansicht von Benutzerfreundlichkeit sieht anders aus; ich fürchte, dass meine Vorstellung von benutzerfreundlichen Namen mit Handarbeit verbunden ist; diese darf man bei Galerieskripten dem Anwender weder zumuten noch überhaupt erlauben. So landet man aus praktischen Erwägungen doch bei generierten Namen :-(

Freundliche Grüße

Vinzenz

[Christian Seiler]

Hallo Vinzenz,

Wie Rouven bereits schrieb, wären in einem solchen Fall Trigger durchaus nett.

Ich weiß nicht, wie's in anderen DBMS aussieht, aber bei Oracle kannst Du das mit dem Trigger vergessen, da ein Trigger auf alle Tabellen in der DB zugreifen darf - bis auf (!) die Tabelle, auf die er gesetzt ist. Das hat damit zu tun, dass die Tabelle in dem Moment, in dem der Trigger läuft, in einem "Zwischenzustand" ist und deswegen gesperrt.

Wenn man den ganzen Code dafür in die DB verlagern will, dann bieten sich nur Stored Procedures an.

Viele Grüße,
Christian

[Vinzenz Mai]

Hallo Christian,

Wie Rouven bereits schrieb, wären in einem solchen Fall Trigger durchaus nett.

Ich weiß nicht, wie's in anderen DBMS aussieht, aber bei Oracle kannst Du das mit dem Trigger vergessen, da ein Trigger auf alle Tabellen in der DB zugreifen darf - bis auf (!) die Tabelle, auf die er gesetzt ist.

beim MS SQL-Server geht das. Du kannst konfigurieren, ob ein Trigger sich selbst rekursiv aufruft oder auch nicht.

Wenn man den ganzen Code dafür in die DB verlagern will, dann bieten sich nur Stored Procedures an.

Inklusive des Umbenennens der Dateien :-) Beim MS SQL-Server 2005 kann man endlich konfigurieren, dass Systemaufrufe mit xp_cmdshell nicht erlaubt sind, das ist erfreulicherweise sogar die Standardeinstellung. Beim MS SQL-Server 2000 (und älter) kann man damit wunderbar gefährliche Sachen machen. Der Windowsprozess, der von xp_cmdshell erzeugt wird, hat die gleichen Rechte wie das SQL-Server-Dienstkonto. Ja, ich weiß, dass dieses Dienstkonto _kein_ Administratorkonto sein sollte. Ich weiß jedoch auch, dass bei vielen Installationen diese Sicherheitsmaßnahme (aus welchen Gründen auch immer) versäumt wird.

Freundliche Grüße

Vinzenz

[Mahmoud D'Rselbst]

Mahlzeit,

Nein, ich bemühe mich schon, zwischen den Zeilen zu lesen - und bestehe nicht auf der Auslegung exakt nach dem Wort.

Anforderungen aufnehmen kann auf ein Lesen in Teerückständen hinauslaufen. Ich habe die Sache nur thematisiert, weil es mir 1.) hinreichend wahrscheinlich schien, dass der Anfordernde ein permanentes benutzerfreundliches Identifikationssystem wünscht und 2.) weil dieses ein kontroverses Thema ist. Viele ITler mögen solche benutzerfreundliche Identifikationssysteme nicht und dann wird in der Diskussion "geholzt". Dass ich benutzerfreundliche Identifikationssysteme für selbstverständlich halte, dürfte klar geworden sein. :)

Wenn es darum gehen sollte, den neuen Namen für das neue Bild zu finden, dann muss die Anwendungslogik verschiedene Fälle betrachten, die im Ausgangsposting nicht erwähnt sind:

Einfügen, die leichte Operation:
Einfügen ist selbstverständlich nur am "Ende" möglich. Soll nur ein neues Bild in die Galerie eingefügt werden, so ist es natürlich Unsinn, Daten aller relevanten Datensätze abzufragen, eventuell sogar bequem mit SELECT * FROM ..., die Daten anzufordern - und wegzuwerfen. Für soetwas gibt es COUNT().

Löschen, die schwierige Operation:
Ist es möglich, ein Bild zu löschen. Wenn ja, müssen innerhalb einer Galerie die Bilder umbenannt werden. Dazu wäre mein Statement als Ansatz brauchbar. Wie Rouven bereits schrieb, wären in einem solchen Fall Trigger durchaus nett. Ich weiß allerdings nicht, wie man die Race Condition zwischen Umbenennen der Dateien, Ändern der Links und Ändern in der Datenbank vermeiden kann. Man könnte sie als unvermeidbar für einen sehr kurzen Zeitraum hinnehmen. Mein Schluss lautete im Anwendungsfall jedoch: verzichte auf das Umbenennen, akzeptiere dass generierte Namen "Lücken" aufweisen.
Die Alternative: Bilder werden nicht gelöscht.

Ich persönlich finde nicht, dass durchnumerierte Bilder wirklich benutzerfreundliche Namen tragen. Meine persönliche Ansicht von Benutzerfreundlichkeit sieht anders aus; ich fürchte, dass meine Vorstellung von benutzerfreundlichen Namen mit Handarbeit verbunden ist; diese darf man bei Galerieskripten dem Anwender weder zumuten noch überhaupt erlauben. So landet man aus praktischen Erwägungen doch bei generierten Namen :-(

Jetzt verstehe zur Abwechslung mal ich "Bahnhof". - Was spricht gegen ein neues Datenfeld mit auto increment, darauf sitzenden Index (für die Eindeutigkeit) und einer am RDBMS angesiedelten Logik, die transaktional für das Fortlaufen des auto increment-Wertes sorgt?
(Wenn sich jetzt herausstellen sollte, dass es kein Datenbank-Problem ist, dann werde ich aber grün im Gesicht. ;)

Viele Grüße!
Mahmoud D'Rselbst

[Vinzenz Mai]

Hallo

Nein, ich bemühe mich schon, zwischen den Zeilen zu lesen - und bestehe nicht auf der Auslegung exakt nach dem Wort.

Anforderungen aufnehmen kann auf ein Lesen in Teerückständen hinauslaufen.

ich mag keinen Tee.

Ich habe die Sache nur thematisiert, weil es mir 1.) hinreichend wahrscheinlich schien, dass der Anfordernde ein permanentes benutzerfreundliches Identifikationssystem wünscht und 2.) weil dieses ein kontroverses Thema ist. Viele ITler mögen solche benutzerfreundliche Identifikationssysteme nicht und dann wird in der Diskussion "geholzt". Dass ich benutzerfreundliche Identifikationssysteme für selbstverständlich halte, dürfte klar geworden sein. :)

Huch, wo habe ich geholzt? In meinem ersten Posting? Als fast gleichlautend zu Sven sagte, dass das Verhalten von Datenbankmanagementsystemen in meinen Augen sinnvoll ist? Als ich dort erwähnte, dass es je nach Umfeld weitere Möglichkeiten gibt? Ich dazu aber genauere Angaben haben müsste?

Wenn es darum gehen sollte, den neuen Namen für das neue Bild zu finden, dann muss die Anwendungslogik verschiedene Fälle betrachten, die im Ausgangsposting nicht erwähnt sind:

Einfügen, die leichte Operation:
Einfügen ist selbstverständlich nur am "Ende" möglich. Soll nur ein neues Bild in die Galerie eingefügt werden, so ist es natürlich Unsinn, Daten aller relevanten Datensätze abzufragen, eventuell sogar bequem mit SELECT * FROM ..., die Daten anzufordern - und wegzuwerfen. Für soetwas gibt es COUNT().

Löschen, die schwierige Operation:
Ist es möglich, ein Bild zu löschen. Wenn ja, müssen innerhalb einer Galerie die Bilder umbenannt werden. Dazu wäre mein Statement als Ansatz brauchbar. Wie Rouven bereits schrieb, wären in einem solchen Fall Trigger durchaus nett. Ich weiß allerdings nicht, wie man die Race Condition zwischen Umbenennen der Dateien, Ändern der Links und Ändern in der Datenbank vermeiden kann. Man könnte sie als unvermeidbar für einen sehr kurzen Zeitraum hinnehmen. Mein Schluss lautete im Anwendungsfall jedoch: verzichte auf das Umbenennen, akzeptiere dass generierte Namen "Lücken" aufweisen.
Die Alternative: Bilder werden nicht gelöscht.

Kannst Du das akzeptieren? Oder verstehst Du hier bereits "Bahnhof"? Ich erkläre es an einem Beispiel:

1. Derzeit sind 85 Bilder in der Galerie.
2. Es wird ein neues Bild hinzugefügt,
   somit bekommt es die Nummer 86 als Suffix im Dateinamen.
3. Bild 47 wird gelöscht.
4. Es wird ein neues Bild hinzugefügt.
   Gleich, welche Methode man anwendet, als Suffix wird
   wieder die Nummer 86 ermittelt. O weh! Ein doppelter
   Dateiname.

Um dieses Problem beim Löschen zu umgehen - und um keine Lücken entstehen zu lassen, müssen somit nach Schritt 3 alle Bilder nach Bild 47 umbenannt werden. Ich gehe davon aus, dass die Bilder als Datei vorliegen und nicht in der Datenbank gespeichert sind, nur der Dateiname (inklusive Pfad). Du solltest leicht erkennen, dass Löschen die aufwendige Operation ist. Hier muss alles angepasst werden.

Ich persönlich finde nicht, dass durchnumerierte Bilder wirklich benutzerfreundliche Namen tragen. Meine persönliche Ansicht von Benutzerfreundlichkeit sieht anders aus; ich fürchte, dass meine Vorstellung von benutzerfreundlichen Namen mit Handarbeit verbunden ist; diese darf man bei Galerieskripten dem Anwender weder zumuten noch überhaupt erlauben. So landet man aus praktischen Erwägungen doch bei generierten Namen :-(

Jetzt verstehe zur Abwechslung mal ich "Bahnhof".

Vielleicht sollte ich es nochmals klarstellen: Irgendwelche Numerierungen halte ich nicht für benutzerfreundlich, egal ob diese lückenlos oder lückenbehaftet sind. Ich kenne von vielen Menschen ihren Wohnort, die Straße, in der sie wohnen - aber nicht die dazugehörende Postleitzahl. Genausowenig finde ich Bildbezeichnungen der Form

galeriethema_galerieunterthema_galerienummer_bildnummer

für irgendwie benutzerfreundlich. Ich mag Bildnamen, die mir im Klartext sagen, was ich auf dem Bild sehe; ich mag Bildnamen mit Leerzeichen; ich mag Bildnamen in Groß- und Kleinschreibung - es ist schon schlimm genug, dass ich gewisse Zeichen nicht verwenden darf, weil das Dateisystm mir diese verbietet.

Quiberon, Blick auf Belle Ile im Abendrot.jpg

oder etwas in dieser Art. Das finde ich benutzerfreundlich. Nicht Nummern, Themen und ähnlicher Kram, der zu interner Strukturierung nötig ist - und oft wenig, zu wenig über den Inhalt aussagt. Ja, ich weiß, dass solche Namen für Galerieskripte ziemlich ungeeignet sind. Ja und?

Urlaub_Bretagne_17_86.jpg

ist für mich genausowenig benutzerfreundlich wie

Urlaub_Bretagne_17_85.jpg (weil gerade ein Bild gelöscht wurde)

• Was spricht gegen ein neues Datenfeld mit auto increment, darauf sitzenden Index (für die Eindeutigkeit) und einer am RDBMS angesiedelten Logik, die transaktional für das Fortlaufen des auto increment-Wertes sorgt?
  (Wenn sich jetzt herausstellen sollte, dass es kein Datenbank-Problem ist, dann werde ich aber grün im Gesicht. ;)

Mehr als ein auto_increment-Wert (oder serial oder identity ...) je Tabelle ist bei handelsüblichen DBMSen unüblich. Es ist auch überflüssig. Du möchtest sauber durchnumerieren. Wo ist das Problem? Wie es genau zu lösen ist, das hängt vom vorliegenden DBMS ab. Bei MySQL sind die Möglichkeiten je nach Version beschränkt bis extrem beschränkt, bei einem anderen DBMS kannst Du fast im Luxus schwelgen. Was ist denn zu tun?

• neue Namen ermitteln
• Tabelle updaten
• Dateien umbenennen
• Links aktualisieren

Bei MS SQL Server könntest Du diese Aufgaben z.B. mit einem Trigger erledigen, eine entsprechende Konfiguration (bis SQL Server 2000 Standard) vorausgesetzt. Wie Christian schrieb, ginge das bei Oracle nicht. Grundsätzlich bin ich der Ansicht, dass es keine gute Idee ist, das Umbenennen der Dateien dem DBMS zu übertragen, das ist in der API besser aufgehoben - selbst dann, wenn es möglich wäre. Ich weiß ehrlich gesagt auch nicht, was bei einem Rollback der Transaktion nach Umbenennen der Dateien passierte. Nein, ich würde es nicht so machen. Somit käme man zu

• neue Namen ermitteln

• Tabelle updaten

und anschließend

• Dateien umbenennen.
• Links aktualisieren

Letzte beiden Aktionen mit Dateilocks absíchern (Dateien sogar für Lesen sperren) und zu einer bekannt zugriffsarmen Zeit durchführen. Ja, ich sehe massive technische Probleme, nur um Namen zu erhalten, die ich persönlich - ja es ist meine persönliche Meinung - kein bißchen benutzerfreundlicher halte als andere Namen, die ich problemlos erhalten kann.

Vielleicht verstehe ich aber auch die Problematik überhaupt nicht oder wir reden aneinander vorbei. Nichts ist unmöglich ...

Freundliche Grüße

Vinzenz

[Mahmoud D'rselbst]

Hi,

Nein, ich bemühe mich schon, zwischen den Zeilen zu lesen - und bestehe nicht auf der Auslegung exakt nach dem Wort.

Anforderungen aufnehmen kann auf ein Lesen in Teerückständen hinauslaufen.

ich mag keinen Tee.

ich mag keine Anforderungen. ;)

(Niemand hat geholzt. Niemand hat behauptet, dass geholzt worden ist. Holzen ist per se aber gar nicht so schlecht.)

Vielleicht sollte ich es nochmals klarstellen: Irgendwelche Numerierungen halte ich nicht für benutzerfreundlich, egal ob diese lückenlos oder lückenbehaftet sind.

Das ist aber nun mal der Fachterminus. Vielleicht leuchtet die "Benutzerfreundlichkeit" (die ja eher ein Synonym ist ;) ein, wenn man sich Vertragsnummern vorstellt?! (Und wütende Kaufleute, denen Vertragsnummern durch die Lappen gegangen sind, und die jetzt befürchten, dass Verträge unter dem eigenen Firmennamen an ihnen vorbei getätigt worden sind.)

Ja, ich weiß, dass solche Namen für Galerieskripte ziemlich ungeeignet sind. Ja und?

Trenne Dich bitte endgültig von der Photogallery-Thematik. :)

Bei MS SQL Server könntest Du diese Aufgaben z.B. mit einem Trigger erledigen, eine entsprechende Konfiguration (bis SQL Server 2000 Standard) vorausgesetzt.

"Setze Trigger ein, wenn erforderlich." - nichts spricht gegen eine SP, eine (zusätzliche) Tabelle für benutzerfreundliche IDs einer DB und eine kleine Transaktion.

Vielleicht verstehe ich aber auch die Problematik überhaupt nicht oder wir reden aneinander vorbei. Nichts ist unmöglich ...

Wir schreiben sicherlich ein wenig aneinander vorbei. Deine Ausführungen zum transaktionssicheren Filesystem-Management sind interessant, wir haben mal an einem "DMS light" herumgebastelt und ähnliche Überlegungen angestellt. (BTW - man kriegt den Zugriff aufs Filesystem schon irgendwie transaktionssicher hin, aber das ist aufwendig und RDBMS-BLOBs sind eine Alternative.)

Du denkst übrigens andauernd darüber nach, wie das Löschen von Datensätzen, die ja fortlaufend sind, zu bearbeiten ist. War das angefordert? ;)
Klar, da würde sich was beissen. Bildchen (äh, jetzt bin ich in der gallery) würden auf einmal mit gleichem Namen anders aussehen.
Nee, beides kann man nicht sinnvollerweise anfordern, also benutzerfreundliche IDs und Löschen bzw. Ersetzen einzelner Datensätze.

VG!
Mahmoud D'Rselbst

[Klaus Mock]

Hallo,

Nee, beides kann man nicht sinnvollerweise anfordern, also benutzerfreundliche IDs und Löschen bzw. Ersetzen einzelner Datensätze.

Irgendwie verstehe ich diesen Wirbel hie rnicht so genau. Eine ID is meiner Meinung nach ein rein technisches Hilfsmittel um eine bestimmte Entität eindeutig zu identifizieren. Das dafür zufällig eine mehr oder weniger aufsteigende Nummer herangezogen werden kann, ist purer Zufall. Genausogut könnte man auch einen Zufalls-String/Zahl oder eine GUID oder was auch immer heranziehen. Im Prinzip ist es egal, solange die ID nur auf immer und ewig eindeutig ist.

Eine Liste an Entitäten durchzunummerieren hat andererseits nicht direkt mit einer Identifikationsmöglichkeit zu tun, sondern eher mit Ergebnissen von Abfragen. Und 'benutzerfreundlich' sind Nummern an sich nie (ausser man ist Buchhalter mit Leib und Seele *g*). Ich bin hier auch Vinzenz's Meinung, dass nur sprechende Bezeichnungen benutzerfrundlich sind. Oder wie findest Du (nur so als Beispiel) das Stück 1 auf der CD 028-0433275-7776528? Alternativ hätte ich Dich natürlich auch nach Deiner Meinung zu 'We Belong Together' von Rickie Lee Jones fragen können;-) Nein Nummer sind praktisch nie benutzerfreundlich.

Grüße
  Klaus

[Mahmoud D'Rselbst]

Hi,

Irgendwie verstehe ich diesen Wirbel hie rnicht so genau.

welchen Wirbel? - Es ist ja nur die Thematik die anspruchsvoll scheint.

Eine ID is meiner Meinung nach ein rein technisches Hilfsmittel um eine bestimmte Entität eindeutig zu identifizieren. Das dafür zufällig eine mehr oder weniger aufsteigende Nummer herangezogen werden kann, ist purer Zufall. Genausogut könnte man auch einen Zufalls-String/Zahl oder eine GUID oder was auch immer heranziehen. Im Prinzip ist es egal, solange die ID nur auf immer und ewig eindeutig ist.

Klar.

Eine Liste an Entitäten durchzunummerieren hat andererseits nicht direkt mit einer Identifikationsmöglichkeit zu tun, sondern eher mit Ergebnissen von Abfragen.

Ein Zähler für "Trefferlisten", auch klar.

Und 'benutzerfreundlich' sind Nummern an sich nie (ausser man ist Buchhalter mit Leib und Seele *g*).

Oder Kaufmann oder arbeitet im Vertrieb. Es ist kein Zufall, dass viele gebraeuchliche Kennungen numerischer Art sind.

Ich bin hier auch Vinzenz's Meinung, dass nur sprechende Bezeichnungen benutzerfrundlich sind. Oder wie findest Du (nur so als Beispiel) das Stück 1 auf der CD 028-0433275-7776528? Alternativ hätte ich Dich natürlich auch nach Deiner Meinung zu 'We Belong Together' von Rickie Lee Jones fragen können;-) Nein Nummer sind praktisch nie benutzerfreundlich.

Nummern sind offensichtlich benutzerfreundlicher als bspw. die bei MS gebräuchlichen GUIDs.

Noch einmal zur Wiederholung:
1.) IDs werden zur eindeutigen Kennzeichnung eines Datensatzes benötigt, diese sind typischerweise bedeutungsfrei.
2.) IDs dürfen gerne auch numerisch sein.
3.) Dann sind diese aber immer noch technisch und nicht benutzerfreundlich.
4.) Benutzerfreundliche IDs werden oft angefordert (Bsp.: Vertragsnummer, Anfragenummern, Ticket-Nummern), oft auch mit der Bedingung "bitte fortlaufend", das ist auch gut so.
5.) Für diesen Zweck taugt dann aber eine technische ID [b]nicht[/b], auch wenn diese sich anzubieten scheint.
6.) Also kommt man typischerweise mit einem neue Datenfeld "benutzerfreundliche ID" (z.B. "VertragUFID").
7.) Das ist auch gut so, Bedenken gegen diese Pflege zweier Identifikationssysteme sind ttypischerweise rein ideologischer Art (und zudem völlig unbegründet, es geht eben nicht einfacher).

Mahmoud

[Auge]

Hallo

6.) Also kommt man typischerweise mit einem neue Datenfeld "benutzerfreundliche ID" (z.B. "VertragUFID").

Diese Nummer wird aber nicht neu vergeben, wie es für die Dateinamen der Bilder von bleicher gewünscht ist. Es handelt sich somit um eine (nichttechnische) ID. Für diese gilt schlussendlich das Gleiche, wie für die ID als auto-increment-Wert in einer DB. Sie wird einmal vergeben und hernach weder geändert noch neu vergeben.

Tschö, Auge

[MudGuard]

Hi,

Und 'benutzerfreundlich' sind Nummern an sich nie (ausser man ist Buchhalter mit Leib und Seele *g*).

Sag niemals nie.

Begib Dich mal nach England und versuche, in einer längeren Straße das Haus mit einem Identifier wie z.B. "Ashdale" zu finden.
Und dann begib Dich nach Deutschland, in eine längere Straße mit aufsteigend sortierten (naja, meist wenigstens annähernd aufsteigend sortierten) Hausnummern, und finde dort das Haus mit einem Identifier wie z.B. 237.

cu,
Andreas

[Rouven]

Hi,

na ja, in Datenbanken die Trigger unterstützen kann man der Datenbank die Aufgabe einer Nummernspalte zukommen lassen, aber von Haus aus dürfte das IIRC nirgendwo dabei sein. Das Problem ist tatsächlich, dass Datenbanken - ORDER BY ausgenommen - modellbedingt nicht viel von Reihenfolgen halten. Wer Reihenfolgen will muss sortieren oder z.B. strukturerhaltende Formate wie XML nehmen. Du könntest die Nummerierung auch von deinem Skript machen lassen, das ja sicherlich irgendwo mit im Spiel ist.

MfG
Rouven

[Sven Rautenberg]

Moin!

Und zwar: ich habe eine SQL tabele in der eien Spalte (id) mit Primarschlüssel und auto_increment versehen ist. Das Problem - wird eine Zeile (zB mit id 5) gelöscht und eine neue hinzugefügt kriegt die neue #6 , auto_increment zählt also weiter ob die vorherige zeile da ist oder nicht.

Die Frage - wie kann ich erreichen , daß die Zeilen eine "ordentliche" Nummerierung kriegen?

Nichts tun!

Eine ID dient ausschließlich der eindeutigen Identifizierung eines Datensatzes - nicht der Numerierung!

Würdest du nach dem Löschen des ersten Datensatzes mit ID 5 erneut einen Datensatz mit der ID 5 speichern können, wäre global betrachtet nicht klar, welcher der zwei existierenden Datensätze mit ID 5 denn nun gemeint sein könnte, wenn anderswo eine Referenz auf die ID 5 auftaucht.

Und behaupte nicht, dass es sowas nicht gibt. Angenommen, du hast zwei Browserfenster mit PHPMyAdmin offen. Das eine Fenster zeigt eine Auflistung deiner Datensätze, unter anderem auch den alten mit der ID 5.

Das zweite Fenster benutzt du nun, um ein wenig herumzuwurschteln, dann löschst du dort die ID 5, und legst einen neuen Datensatz mit ID 5 an.

Und dann gehst du zum alten Fenster, siehst: Ups, der Datensatz ID 5 ist ja falsch, der gehört gelöscht - klick... und schon ist dein neuer Datensatz im Orkus!

Entsprechend ausgeschmückte Geschichten gibts übrigens in diesem Forum sehr häufig, weil offenbar alle Datenbankanfänger auf die Idee kommen, die ID wäre sowas wie eine Datensatznumerierung, die bitte fortlaufend zu sein hat. "Siehe Archiv[tm]".

- Sven Rautenberg