Rücksprung-Seite berechnen

Servus!

Folgendes Problem: Aus einer Liste von Elementen, die auf mehrere Seiten
aufgeteilt ist, soll nach dem Sprung auf eine Detailseite ein Link auf
die Seite der Liste angezeigt werden, von der der Benutzer kam.
Also bräuchte ich quasi einen Query, der mir die Position eines
Elementes innerhalb der Liste aller verfügbaren Elemente angibt.

Gibts sowas in MySQL?

Was ich zu vermeiden versuche ist:
- ein javascript:history.back()-Link
- dass die Listenseite ihre Nummer mit-übergibt damit man dahin
zurückspringen kann
- dass ich in der Detailansicht durch alle Treffer der Liste iterieren
muss um die Position des gewünschten Elements herhauszufinden.

Zur Not werde ich halt letzteres umsetzen.

Gruß,
Daniel Fett
--
www.danielfett.de

Re: Rücksprung-Seite berechnen

Hi Daniel

Daniel Fett wrote:
> Folgendes Problem: Aus einer Liste von Elementen, die auf mehrere Seiten
> aufgeteilt ist, soll nach dem Sprung auf eine Detailseite ein Link auf
> die Seite der Liste angezeigt werden, von der der Benutzer kam.
> Also bräuchte ich quasi einen Query, der mir die Position eines
> Elementes innerhalb der Liste aller verfügbaren Elemente angibt.
> Gibts sowas in MySQL?

Wo ist der Zusammenhang zu MySQL? Speicher doch einfach die Position in
die Session und schon kannst du darauf referenzieren.

> Was ich zu vermeiden versuche ist:
> - ein javascript:history.back()-Link
> - dass die Listenseite ihre Nummer mit-übergibt damit man dahin
> zurückspringen kann

Ich denke, es stört dich, diesen Parameter über POST/GET zu übergeben.
OK wäre es aber, in der Session diesen Wert zu lagern.

> - dass ich in der Detailansicht durch alle Treffer der Liste iterieren
> muss um die Position des gewünschten Elements herhauszufinden.
> Zur Not werde ich halt letzteres umsetzen.

HTH, Johannes

Re: Rücksprung-Seite berechnen

Moin!

Johannes Vogel wrote:
> Hi Daniel
>
> Daniel Fett wrote:
>
>> Folgendes Problem: Aus einer Liste von Elementen, die auf mehrere
>> Seiten aufgeteilt ist, soll nach dem Sprung auf eine Detailseite ein
>> Link auf die Seite der Liste angezeigt werden, von der der Benutzer kam.
>> Also bräuchte ich quasi einen Query, der mir die Position eines
>> Elementes innerhalb der Liste aller verfügbaren Elemente angibt.
>> Gibts sowas in MySQL?
>
>
> Wo ist der Zusammenhang zu MySQL? Speicher doch einfach die Position in
> die Session und schon kannst du darauf referenzieren.

(Ich hab ja schon geahnt, dass so eine Bemerkung kommt...) Der
Zusmammenhang besteht darin, dass meine Frage auf eine MySQL-Lösung
abzielt, da alle anderen Lösungen für mich überschaubar sind.
Klar _kann_ ich es ohne MySQL machen. Aber ich wollte ja eben wissen,
ob's da nicht was von Ratio^WMySQL gibt. Daher .datenbanken und nicht .misc.

>
>> Was ich zu vermeiden versuche ist:
>> - ein javascript:history.back()-Link
>> - dass die Listenseite ihre Nummer mit-übergibt damit man dahin
>> zurückspringen kann
>
>
> Ich denke, es stört dich, diesen Parameter über POST/GET zu übergeben.
> OK wäre es aber, in der Session diesen Wert zu lagern.

Jop, wäre eine Lösung. Ist aber ungünstig für Links von Extern oder von
wo anders auf der Site. Und wenn von dort ein Benutzer kommt, will ich
ihn nicht gerne ins kalte Wasser werfen, wenn er dann auf die gesamte
Liste springt.
Außerdem hab ich bisher keine Session und muss ja nun auch nicht
unbedingt dafür eine anlegen, wenns auch anders geht.

Gruß,
Daniel Fett

--
www.danielfett.de

Re: Rücksprung-Seite berechnen

Daniel Fett wrote:

>>> Folgendes Problem: Aus einer Liste von Elementen, die auf mehrere
>>> Seiten aufgeteilt ist, soll nach dem Sprung auf eine Detailseite ein
>>> Link auf die Seite der Liste angezeigt werden, von der der Benutzer kam.
>>> Also bräuchte ich quasi einen Query, der mir die Position eines
>>> Elementes innerhalb der Liste aller verfügbaren Elemente angibt.
>>> Gibts sowas in MySQL?

Wie sollte das funktionieren? Irgendeinen Parameter muss man immer
zwischen den Seiten mitschleppen (Protokoll zustandslos, eh schon
wissen...) Ob der Parameter als GET, POST, SESSION mitkommt ist zunächst
mal zweitrangig.

>> Wo ist der Zusammenhang zu MySQL? Speicher doch einfach die Position
>> in die Session und schon kannst du darauf referenzieren.
>
>
> (Ich hab ja schon geahnt, dass so eine Bemerkung kommt...) Der
> Zusmammenhang besteht darin, dass meine Frage auf eine MySQL-Lösung
> abzielt, da alle anderen Lösungen für mich überschaubar sind.

Muss man diesen Satz verstehen?

> Klar _kann_ ich es ohne MySQL machen. Aber ich wollte ja eben wissen,
> ob's da nicht was von Ratio^WMySQL gibt. Daher .datenbanken und nicht
> .misc.

Das muss man jetzt endgültig nicht verstehen. Du willst also MySQL für
irgendwas verwenden, damit es verwendet ist. Richtig?

>>
>>> Was ich zu vermeiden versuche ist:
>>> - ein javascript:history.back()-Link
>>> - dass die Listenseite ihre Nummer mit-übergibt damit man dahin
>>> zurückspringen kann

Deshalb nimmt man evtl. Sessions.

> Jop, wäre eine Lösung. Ist aber ungünstig für Links von Extern oder von
> wo anders auf der Site. Und wenn von dort ein Benutzer kommt, will ich
> ihn nicht gerne ins kalte Wasser werfen, wenn er dann auf die gesamte
> Liste springt.

???

> Außerdem hab ich bisher keine Session und muss ja nun auch nicht
> unbedingt dafür eine anlegen, wenns auch anders geht.

Puh. Stimmt. session_start() ist schon mächtig viel Aufwand...


Gruß, Gregor


--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Re: Rücksprung-Seite berechnen

Gregor Kofler wrote:
> Daniel Fett wrote:
>
>>>> Folgendes Problem: Aus einer Liste von Elementen, die auf mehrere
>>>> Seiten aufgeteilt ist, soll nach dem Sprung auf eine Detailseite ein
>>>> Link auf die Seite der Liste angezeigt werden, von der der Benutzer
>>>> kam.
>>>> Also bräuchte ich quasi einen Query, der mir die Position eines
>>>> Elementes innerhalb der Liste aller verfügbaren Elemente angibt.
>>>> Gibts sowas in MySQL?
>
>
> Wie sollte das funktionieren? Irgendeinen Parameter muss man immer
> zwischen den Seiten mitschleppen (Protokoll zustandslos, eh schon
> wissen...) Ob der Parameter als GET, POST, SESSION mitkommt ist zunächst
> mal zweitrangig.

Klar, die Detailseite muss ja wissen welches Element sie anzeigen muss.
Das mache ich mit GET und das ist auch völlig in Ordnung.
Ich will nun aber vermeiden, dass sie auch wissen muss, auf welcher
Seite dieses in der Liste aller Elemente steht.

Ich wills mal in Pseudo-SQL formulieren:
SELECT elemente.*, nr() AS allOverId FROM elemente WHERE id = 15
und dann hab ich in allOverId eine Zahl, die mir angibt, um das
wievielte Element es sich handelt, wenn ich WHERE weggelassen hätte.

Damit könnte ich die Seite, zu der zurückgesprungen werden soll, berechnen.

>>> Wo ist der Zusammenhang zu MySQL? Speicher doch einfach die Position
>>> in die Session und schon kannst du darauf referenzieren.
>>
>> (Ich hab ja schon geahnt, dass so eine Bemerkung kommt...) Der
>> Zusmammenhang besteht darin, dass meine Frage auf eine MySQL-Lösung
>> abzielt, da alle anderen Lösungen für mich überschaubar sind.
>
> Muss man diesen Satz verstehen?

Eigentlich schon. Welcher Teil des Satzes bereitet dir denn Probleme?

Ich kann das "Problem" lösen. Nun wollte ich von euch aber gerne
erfahren, ob es auch eine nur-MySQL-Lösung gibt.

>> Klar _kann_ ich es ohne MySQL machen. Aber ich wollte ja eben wissen,
>> ob's da nicht was von Ratio^WMySQL gibt. Daher .datenbanken und nicht
>> .misc.
>
> Das muss man jetzt endgültig nicht verstehen. Du willst also MySQL für
> irgendwas verwenden, damit es verwendet ist. Richtig?

Nein, ich will zusätzliche Schritte in PHP sparen, wenns das geht. Wenns
nicht geht, ist das auch okay.

>>>> Was ich zu vermeiden versuche ist:
>>>> - ein javascript:history.back()-Link
>>>> - dass die Listenseite ihre Nummer mit-übergibt damit man dahin
>>>> zurückspringen kann
>
> Deshalb nimmt man evtl. Sessions.

Das löst nicht das Problem. Schließlich ist keine Session gesetzt, wenn
von extern auf die Detailseite gelinkt wird.

>
>> Jop, wäre eine Lösung. Ist aber ungünstig für Links von Extern oder
>> von wo anders auf der Site. Und wenn von dort ein Benutzer kommt, will
>> ich ihn nicht gerne ins kalte Wasser werfen, wenn er dann auf die
>> gesamte Liste springt.
>

S.o.: Keine Session gesetzt -> Keine Rücksprung-Seite gespeichert -> Ich
müsste den Benutzer an den Anfang der Liste schicken, wenn er zu dieser
zurück will.

>
>> Außerdem hab ich bisher keine Session und muss ja nun auch nicht
>> unbedingt dafür eine anlegen, wenns auch anders geht.
>
>
> Puh. Stimmt. session_start() ist schon mächtig viel Aufwand

Bitte spar dir die Ironie. Nein, das ist kein Aufwand, bestimmt nicht.
Ich bin auch ganz und gar nicht Sessionphob. Aber die Session wär aus
oben genanntem Grund nur eine halbherzige Lösung und daher ziehe ich
lieber eine Lösung die ohne Sessions auskommt und immer funktioniert vor.


Wie es aussieht gibt es das, was ich oben formuliert habe, aber nicht in
MySQL. Das beantwortet meine Frage. Zugegebenermaßen wäre es auch eine
Funktion die man nicht oft braucht. Sonst wäre das Problem hier
wahrscheinlich auch früher verstanden worden.

Daniel Fett

--
www.danielfett.de

Re: Rücksprung-Seite berechnen

Daniel Fett wrote:

> Klar, die Detailseite muss ja wissen welches Element sie anzeigen muss.
> Das mache ich mit GET und das ist auch völlig in Ordnung.
> Ich will nun aber vermeiden, dass sie auch wissen muss, auf welcher
> Seite dieses in der Liste aller Elemente steht.
>
> Ich wills mal in Pseudo-SQL formulieren:
> SELECT elemente.*, nr() AS allOverId FROM elemente WHERE id = 15
> und dann hab ich in allOverId eine Zahl, die mir angibt, um das
> wievielte Element es sich handelt, wenn ich WHERE weggelassen hätte.
>
> Damit könnte ich die Seite, zu der zurückgesprungen werden soll, berechnen.

Wenn Primärschlüssel per Autoinkrement generiert werden:

select count(*) from foo where id <= ...

fertig.

Eine präzisere Problembeschreibung hätte schneller geholfen.


Gregor



--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Re: Rücksprung-Seite berechnen

Gregor Kofler wrote:
> Daniel Fett wrote:
>
>> Klar, die Detailseite muss ja wissen welches Element sie anzeigen
>> muss. Das mache ich mit GET und das ist auch völlig in Ordnung.
>> Ich will nun aber vermeiden, dass sie auch wissen muss, auf welcher
>> Seite dieses in der Liste aller Elemente steht.
>>
>> Ich wills mal in Pseudo-SQL formulieren:
>> SELECT elemente.*, nr() AS allOverId FROM elemente WHERE id = 15
>> und dann hab ich in allOverId eine Zahl, die mir angibt, um das
>> wievielte Element es sich handelt, wenn ich WHERE weggelassen hätte.
>>
>> Damit könnte ich die Seite, zu der zurückgesprungen werden soll,
>> berechnen.
>
>
> Wenn Primärschlüssel per Autoinkrement generiert werden:
>
> select count(*) from foo where id <= ...

*an die Stirn klatsch*
Oh Mann, und dafür so ein langer Thread. Klar, geht, danke.

Daniel


--
www.danielfett.de

Re: Rücksprung-Seite berechnen

Hi Gregor

Gregor Kofler wrote:
> Daniel Fett wrote:
>> Klar, die Detailseite muss ja wissen welches Element sie anzeigen
>> muss. Das mache ich mit GET und das ist auch völlig in Ordnung.
>> Ich will nun aber vermeiden, dass sie auch wissen muss, auf welcher
>> Seite dieses in der Liste aller Elemente steht.
>> Ich wills mal in Pseudo-SQL formulieren:
>> SELECT elemente.*, nr() AS allOverId FROM elemente WHERE id = 15
>> und dann hab ich in allOverId eine Zahl, die mir angibt, um das
>> wievielte Element es sich handelt, wenn ich WHERE weggelassen hätte.
>> Damit könnte ich die Seite, zu der zurückgesprungen werden soll,
>> berechnen.
> Wenn Primärschlüssel per Autoinkrement generiert werden:
> select count(*) from foo where id <= ...
> fertig.
> Eine präzisere Problembeschreibung hätte schneller geholfen.

NIE soll nach auto-increment-ID sortiert werden! Denn diese ID hat
keinen erkennbaren Sortier-Nutzen.
*noch-mehr-an-den-kopf-klatsch* (aber irgendwie anders gemeint) SCNR

Nein, das ist Blödsinn. Stattdessen könnte man aber mit MySQL-User
Variablen arbeiten:

set @nr=0; select id,@nr:=@nr+1 from tmp order by ...;

Danach müsste man wiederum den richtigen Datensatz per PHP o.ä.
extrahieren. Aber m.E. ist das alles Gebastel...

Einfacher und ohne DB: Man setze eine Sessionvariable, welche auch über
GET/POST überschrieben werden kann:
if (!empty($_GET['nr']) && is_integer($_GET['nr']))
$_SESSION['nr'] = $_GET['nr'];
if (!empty($_POST['nr']) && is_integer($_POST['nr']))
$_SESSION['nr'] = $_POST['nr'];

Die Möglichkeit, diese als Bookmark zu speichern, sei aber eh zu
hinterfragen. Die Anzahl der Einträge kann sich ja wahrscheinlich
ändern, auch vielleicht die Sortierung der Liste. Dann wird diese Zahl
hinfällig und macht keinen Sinn mehr.

Nicht die Mechanik, sondern die Logik muss IMHO hinterfragt werden.
HTH, Johannes

Re: Rücksprung-Seite berechnen

Johannes Vogel wrote:

>> Wenn Primärschlüssel per Autoinkrement generiert werden:
>> select count(*) from foo where id <= ...
>> fertig.
>> Eine präzisere Problembeschreibung hätte schneller geholfen.
>
> NIE soll nach auto-increment-ID sortiert werden! Denn diese ID hat
> keinen erkennbaren Sortier-Nutzen.
> *noch-mehr-an-den-kopf-klatsch* (aber irgendwie anders gemeint) SCNR

Tlw. ACK. Ich setze normalerweise Timestamps bei der Generierung für
evtl. solche Zwecke. Die auto-increment-ID hat IMO insofern einen
"Sortier-Nutzen" als dass sie aufsteigend vergeben wird. Lücken sind
selbstredend üblich.

> Nein, das ist Blödsinn. Stattdessen könnte man aber mit MySQL-User
> Variablen arbeiten:
>
> set @nr=0; select id,@nr:=@nr+1 from tmp order by ...;

Und nach was sortierst du? Wäre ja IMO das gleiche wie oben, mit einer
sortierfähigen Spalte.

> Danach müsste man wiederum den richtigen Datensatz per PHP o.ä.
> extrahieren. Aber m.E. ist das alles Gebastel...
>
> Einfacher und ohne DB: Man setze eine Sessionvariable, welche auch über
> GET/POST überschrieben werden kann:
> if (!empty($_GET['nr']) && is_integer($_GET['nr']))
> $_SESSION['nr'] = $_GET['nr'];
> if (!empty($_POST['nr']) && is_integer($_POST['nr']))
> $_SESSION['nr'] = $_POST['nr'];

Das wurde von anderen (und mir) schon angeregt - der OP wollte das aber
nicht.

> Die Möglichkeit, diese als Bookmark zu speichern, sei aber eh zu
> hinterfragen. Die Anzahl der Einträge kann sich ja wahrscheinlich
> ändern, auch vielleicht die Sortierung der Liste. Dann wird diese Zahl
> hinfällig und macht keinen Sinn mehr.

ACK. Schreib's nicht mir, schreib's dem OP. ;-)

Gruß, Gregor



--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Re: Rücksprung-Seite berechnen

Gregor Kofler wrote:
> Die auto-increment-ID hat IMO insofern einen=20
> "Sortier-Nutzen" als dass sie aufsteigend vergeben wird.=20

richtig

> Lücken sind selbstredend üblich.

das hängt vom Table-Handler ab, MyISAM zb. vergibt ohne
Lücken, bei InnoDB Transaktionen ist dagegen eine in einer
Transaktion vergebene ID 'verloren' wenn später ein
(implizites oder explizites) ROLLBACK erfolgt. Da in diesem
Fall nich beide Eigenschaften 'lückenlos' und 'aufsteigend'
erfüllt werden können wird nur 'aufsteigend' garantiert.

--=20
Hartmut Holzgraefe, Senior Support Engineer .
MySQL AB, www.mysql.com

http://www.mysql.com/support/

Re: Rücksprung-Seite berechnen

Hartmut Holzgraefe schrieb:
> Gregor Kofler wrote:
>=20
>> Die auto-increment-ID hat IMO insofern einen "Sortier-Nutzen" als dass=
=20
>> sie aufsteigend vergeben wird.=20
>=20
>=20
> richtig
>=20
>> Lücken sind selbstredend üblich.
>=20
>=20
> das hängt vom Table-Handler ab, MyISAM zb. vergibt ohne
> Lücken, bei InnoDB Transaktionen ist dagegen eine in einer
> Transaktion vergebene ID 'verloren' wenn später ein
> (implizites oder explizites) ROLLBACK erfolgt. Da in diesem
> Fall nich beide Eigenschaften 'lückenlos' und 'aufsteigend'
> erfüllt werden können wird nur 'aufsteigend' garantiert.
>=20

Ich denke es ging Gregor auch um die Löschung von Datensätzen, wodurc=
h=20
_immer_ Lücken entstehen.

--=20
Gruss,
Fabian

Re: Rücksprung-Seite berechnen

Hi Gregor

Gregor Kofler wrote:
> Johannes Vogel wrote:
>>> Wenn Primärschlüssel per Autoinkrement generiert werden:
>>> select count(*) from foo where id <= ...
>>> fertig.
>>> Eine präzisere Problembeschreibung hätte schneller geholfen.
>> NIE soll nach auto-increment-ID sortiert werden! Denn diese ID hat
>> keinen erkennbaren Sortier-Nutzen.
>> *noch-mehr-an-den-kopf-klatsch* (aber irgendwie anders gemeint) SCNR
> Tlw. ACK. Ich setze normalerweise Timestamps bei der Generierung für
> evtl. solche Zwecke. Die auto-increment-ID hat IMO insofern einen
> "Sortier-Nutzen" als dass sie aufsteigend vergeben wird. Lücken sind
> selbstredend üblich.

a) sind Timestamps nicht eindeutig, weil zwei Prozesse locker in der
selben Sekunde schreiben können und b) weshalb soll die Liste historisch
sortiert werden? Und weshalb soll dies auch in Zukunft auch so sein? Ich
stelle gerne erneut die Frage des OP in Frage.

>> Nein, das ist Blödsinn. Stattdessen könnte man aber mit MySQL-User
>> Variablen arbeiten:
>> set @nr=0; select id,@nr:=@nr+1 from tmp order by ...;
> Und nach was sortierst du? Wäre ja IMO das gleiche wie oben, mit einer
> sortierfähigen Spalte.

Du möchtest ja per <= den gesuchten Tupel berechnen lassen. Wenn du nun
absteigend sortierst musst du bereits den <= zum >= ändern. Nun gut, die
Lösung wäre auch möglich bei String-Sortierungen - trotzdem will sie mir
nicht gefallen. Tschuldige.. :-)

>> Danach müsste man wiederum den richtigen Datensatz per PHP o.ä.
>> extrahieren. Aber m.E. ist das alles Gebastel...
>> Einfacher und ohne DB: Man setze eine Sessionvariable, welche auch
>> über GET/POST überschrieben werden kann:
> Das wurde von anderen (und mir) schon angeregt - der OP wollte das aber
> nicht.

Wir beiden sind die einzigen, die geantwortet haben. Ich wollte auf
dieser Möglichkeit sistieren.

>> Die Möglichkeit, diese als Bookmark zu speichern, sei aber eh zu
>> hinterfragen. Die Anzahl der Einträge kann sich ja wahrscheinlich
>> ändern, auch vielleicht die Sortierung der Liste. Dann wird diese Zahl
>> hinfällig und macht keinen Sinn mehr.
> ACK. Schreib's nicht mir, schreib's dem OP. ;-)

Ja, sorry... Ich mach doch nicht noch ein Posting... Ich denke, er wird
wohl den ganzen Thread lesen. Hoffentlich...
Und wer bookmarkt sich übrigens schon einzelne Seiten in einer
seitenweisen Ausgabe?

EOD, Johannes

Re: Rücksprung-Seite berechnen

Johannes Vogel wrote:

> a) sind Timestamps nicht eindeutig, weil zwei Prozesse locker in der
> selben Sekunde schreiben können und b) weshalb soll die Liste historisch
> sortiert werden? Und weshalb soll dies auch in Zukunft auch so sein? Ich
> stelle gerne erneut die Frage des OP in Frage.

ad a: Ja und? In dem Fall ist die Reihenfolge der Datensätze des
gleichen Zeitpunkt "zufällig". Für die reine Sortierung ist das IMO
meist wenig tragisch. Der OP hat damit evtl. ein Problem.

ad b: Ich sprach von der Timestamp-Sortierung als Ersatz für die
ID-Sortierung, die ja auch eine "historische" ist.


> Wir beiden sind die einzigen, die geantwortet haben. Ich wollte auf
> dieser Möglichkeit sistieren.

Ah ja - stimmt. :-)

> EOD, Johannes

Ok. Gregor



--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Re: Rücksprung-Seite berechnen

> Jop, wäre eine Lösung. Ist aber ungünstig für Links von Extern oder von
> wo anders auf der Site. Und wenn von dort ein Benutzer kommt, will ich
> ihn nicht gerne ins kalte Wasser werfen, wenn er dann auf die gesamte
> Liste springt.

Unter Umständen willst Du die Liste filter- und sortierbar gestalten -
dann gibt es von einem "externen" Link zu einer Detailseite aber keine
eindeutige Liste mehr.

=> Ich würde auch die Session verwenden.

Re: Rücksprung-Seite berechnen

Johannes Vogel wrote:
> Hi Gregor
>
> Gregor Kofler wrote:
>
>> Daniel Fett wrote:
>>
>>> Klar, die Detailseite muss ja wissen welches Element sie anzeigen
>>> muss. Das mache ich mit GET und das ist auch völlig in Ordnung.
>>> Ich will nun aber vermeiden, dass sie auch wissen muss, auf welcher
>>> Seite dieses in der Liste aller Elemente steht.
>>> Ich wills mal in Pseudo-SQL formulieren:
>>> SELECT elemente.*, nr() AS allOverId FROM elemente WHERE id = 15
>>> und dann hab ich in allOverId eine Zahl, die mir angibt, um das
>>> wievielte Element es sich handelt, wenn ich WHERE weggelassen hätte.
>>> Damit könnte ich die Seite, zu der zurückgesprungen werden soll,
>>> berechnen.
>>
>> Wenn Primärschlüssel per Autoinkrement generiert werden:
>> select count(*) from foo where id <= ...
>> fertig.
>> Eine präzisere Problembeschreibung hätte schneller geholfen.
>
>
> NIE soll nach auto-increment-ID sortiert werden! Denn diese ID hat
> keinen erkennbaren Sortier-Nutzen.

Versteh ich nicht. Meinem Verständnis nach kann ich wohl danach
sortieren, denn dann krieg ich ja die Anzahl der Einträge, die kleiner
sind, auch wenn Lücken und so drin sind. Wo ist das Problem? Warum sind
die woanders vorgeschlagenen Timestamps besser?

> Nein, das ist Blödsinn. Stattdessen könnte man aber mit MySQL-User
> Variablen arbeiten:
>
> set @nr=0; select id,@nr:=@nr+1 from tmp order by ...;

Jau, die Möglichkeit hatte ich mir auch schon angeschaut.

>
> Danach müsste man wiederum den richtigen Datensatz per PHP o.ä.
> extrahieren. Aber m.E. ist das alles Gebastel...

Right.

>
> Einfacher und ohne DB: Man setze eine Sessionvariable, welche auch über
> GET/POST überschrieben werden kann:
> if (!empty($_GET['nr']) && is_integer($_GET['nr']))
> $_SESSION['nr'] = $_GET['nr'];
> if (!empty($_POST['nr']) && is_integer($_POST['nr']))
> $_SESSION['nr'] = $_POST['nr'];
>
> Die Möglichkeit, diese als Bookmark zu speichern, sei aber eh zu
> hinterfragen. Die Anzahl der Einträge kann sich ja wahrscheinlich
> ändern, auch vielleicht die Sortierung der Liste. Dann wird diese Zahl
> hinfällig und macht keinen Sinn mehr.

Richtig, dann ändert sich auch die Seite. Daher hier wieder das Problem
externer Links.

> Nicht die Mechanik, sondern die Logik muss IMHO hinterfragt werden.

Nein, schließlich ist es ja - wie gesagt - kein Problem. Ich wollte ja
nur wissen, ob es in MySQL geht.


--
www.danielfett.de

Re: Rücksprung-Seite berechnen

Johannes Vogel wrote:
> Hi Gregor
>
> Gregor Kofler wrote:
>
>> Johannes Vogel wrote:
>>
>>>> Wenn Primärschlüssel per Autoinkrement generiert werden:
>>>> select count(*) from foo where id <= ...
>>>> fertig.
>>>> Eine präzisere Problembeschreibung hätte schneller geholfen.
>>>
>>> NIE soll nach auto-increment-ID sortiert werden! Denn diese ID hat
>>> keinen erkennbaren Sortier-Nutzen.
>>> *noch-mehr-an-den-kopf-klatsch* (aber irgendwie anders gemeint) SCNR
>>
>> Tlw. ACK. Ich setze normalerweise Timestamps bei der Generierung für
>> evtl. solche Zwecke. Die auto-increment-ID hat IMO insofern einen
>> "Sortier-Nutzen" als dass sie aufsteigend vergeben wird. Lücken sind
>> selbstredend üblich.
>
>
> a) sind Timestamps nicht eindeutig, weil zwei Prozesse locker in der
> selben Sekunde schreiben können und b) weshalb soll die Liste historisch
> sortiert werden? Und weshalb soll dies auch in Zukunft auch so sein? Ich
> stelle gerne erneut die Frage des OP in Frage.

Ja, es soll historisch sortiert werden. Ja, nach auto-increment-id. Es
scheint mir so, als löse die Sache mit <= id mein Problem.

> Ja, sorry... Ich mach doch nicht noch ein Posting... Ich denke, er wird
> wohl den ganzen Thread lesen. Hoffentlich...

Jop, tut er.

> Und wer bookmarkt sich übrigens schon einzelne Seiten in einer
> seitenweisen Ausgabe?

Wenn die Detailseiten Artikel sind und die Liste die Liste aller Artikel
- warum nicht? Es geht ja auch um externe Links. Daher keine
GET/POST/SESSION-Sachen, oder habe ich ein Argument/eine Lösung dafür
übersehen?

Speziell für das Seite-ändert-sich-Problem und das
Session-nicht-gesetzt-Problem, meine ich.

Daniel Fett

--
www.danielfett.de

Re: Rücksprung-Seite berechnen

Helmut Schmuckermair wrote:
>> Jop, wäre eine Lösung. Ist aber ungünstig für Links von Extern oder
>> von wo anders auf der Site. Und wenn von dort ein Benutzer kommt, will
>> ich ihn nicht gerne ins kalte Wasser werfen, wenn er dann auf die
>> gesamte Liste springt.
>
>
> Unter Umständen willst Du die Liste filter- und sortierbar gestalten -
> dann gibt es von einem "externen" Link zu einer Detailseite aber keine
> eindeutige Liste mehr.

Richtig, dann wäre eine Session optimal. Will ich aber nicht, trotzdem
danke!

Daniel
--
www.danielfett.de

Re: Rücksprung-Seite berechnen

Hi Daniel

Daniel Fett wrote:
> Johannes Vogel wrote:
>> NIE soll nach auto-increment-ID sortiert werden! Denn diese ID hat
>> keinen erkennbaren Sortier-Nutzen.
> Versteh ich nicht. Meinem Verständnis nach kann ich wohl danach
> sortieren, denn dann krieg ich ja die Anzahl der Einträge, die kleiner
> sind, auch wenn Lücken und so drin sind. Wo ist das Problem? Warum sind
> die woanders vorgeschlagenen Timestamps besser?

Ein künstlicher Schlüssel ist ein sinnfreier völlig willkürrlicher
Mechanismus einem Tupel zur Referenzierung eine Identität zu vergeben.
Ob dies durch Auto-Incremenet geschieht oder durch wahlloses zufälliges
vergeben einer Zahl oder Zeichen / Buchstaben spielt eigentlich keine
Rolle. Die Auto Increment ist deshalb effizient, weil erst nach Ablauf
des Wertebereichs erste Probleme mit Überschneidungen passieren können.

Mit diesem Hintergrund zeigt sich, dass es sinnfrei ist, dem Benutzer in
irgendeiner weise diese ID zu zeigen oder darauf zu referenzieren. Auch
nicht für Sortierzwecke.

Du hast Artikel in deiner DB. Wenn diese Artikel mehr als 30 (?) Stück
werden, wirst du sie sortieren wollen, damit du die gewünschten Artikel
schneller in der Liste findest. Weshalb soll diese Sortierung nach der
Eingabe ins System erfolgen?

Ach, du hast sowas wie ein Blog / Tagebuch? Dann setzt du besser eine
Zeitspalte und sortierst nach dieser. Du hast einen Titel? Oder
Kategorie? Dann wirst du früher oder später danach sortieren wollen.

Vielleicht solltest du uns mehr über dein Projekt verraten?

>> Einfacher und ohne DB: Man setze eine Sessionvariable, welche auch
>> über GET/POST überschrieben werden kann:
>> if (!empty($_GET['nr']) && is_integer($_GET['nr']))
>> $_SESSION['nr'] = $_GET['nr'];
>> if (!empty($_POST['nr']) && is_integer($_POST['nr']))
>> $_SESSION['nr'] = $_POST['nr'];
>> Die Möglichkeit, diese als Bookmark zu speichern, sei aber eh zu
>> hinterfragen. Die Anzahl der Einträge kann sich ja wahrscheinlich
>> ändern, auch vielleicht die Sortierung der Liste. Dann wird diese Zahl
>> hinfällig und macht keinen Sinn mehr.
> Richtig, dann ändert sich auch die Seite. Daher hier wieder das Problem
> externer Links.

?

>> Nicht die Mechanik, sondern die Logik muss IMHO hinterfragt werden.
> Nein, schließlich ist es ja - wie gesagt - kein Problem. Ich wollte ja
> nur wissen, ob es in MySQL geht.

Ich bin nicht schlauer, was du eigentlich vorhast.

Johannes

Re: Rücksprung-Seite berechnen

Johannes Vogel wrote:
> Hi Daniel
>
> Daniel Fett wrote:
>
>> Johannes Vogel wrote:
>>
>>> NIE soll nach auto-increment-ID sortiert werden! Denn diese ID hat
>>> keinen erkennbaren Sortier-Nutzen.
>>
>> Versteh ich nicht. Meinem Verständnis nach kann ich wohl danach
>> sortieren, denn dann krieg ich ja die Anzahl der Einträge, die kleiner
>> sind, auch wenn Lücken und so drin sind. Wo ist das Problem? Warum
>> sind die woanders vorgeschlagenen Timestamps besser?
>
>
> Ein künstlicher Schlüssel ist ein sinnfreier völlig willkürrlicher
> Mechanismus einem Tupel zur Referenzierung eine Identität zu vergeben.
> Ob dies durch Auto-Incremenet geschieht oder durch wahlloses zufälliges
> vergeben einer Zahl oder Zeichen / Buchstaben spielt eigentlich keine
> Rolle. Die Auto Increment ist deshalb effizient, weil erst nach Ablauf
> des Wertebereichs erste Probleme mit Überschneidungen passieren können.
>
> Mit diesem Hintergrund zeigt sich, dass es sinnfrei ist, dem Benutzer in
> irgendeiner weise diese ID zu zeigen oder darauf zu referenzieren. Auch
> nicht für Sortierzwecke.
>
> Du hast Artikel in deiner DB. Wenn diese Artikel mehr als 30 (?) Stück
> werden, wirst du sie sortieren wollen, damit du die gewünschten Artikel
> schneller in der Liste findest. Weshalb soll diese Sortierung nach der
> Eingabe ins System erfolgen?
>
> Ach, du hast sowas wie ein Blog / Tagebuch? Dann setzt du besser eine
> Zeitspalte und sortierst nach dieser. Du hast einen Titel? Oder
> Kategorie? Dann wirst du früher oder später danach sortieren wollen.

Okay, die Ausführungen machen Sinn. Aber ein Auto-Increment wird ja
nicht zufällig vergeben, sondern halt pro Eintrag inkrementiert. Daher
hat eine Sortierung danach eine historische Reihenfolge ohne dass es mir
passieren könnte das plötzlich zwei gleiche auftauchen, oder nicht?
Und ich gehe einfach mal davon aus, dass der Wertebereich groß genug
gewählt ist..

>
> Vielleicht solltest du uns mehr über dein Projekt verraten?

In der Tat handelt es sich um einen Blog auf der in der Signatur
genannten Seite. Im Moment habe ich mal weder ein Archiv noch irgend
eine Sortierung implementiert und daher böserweise nach
auto-increment-IDs sortiert :-)
Die Sortierung hol ich dann irgendwann nach, wenn es mal ein paar mehr
Einträge werden.

Daniel

--
www.danielfett.de

Re: Rücksprung-Seite berechnen

Hi Daniel

Daniel Fett wrote:
> Johannes Vogel wrote:
>> Ach, du hast sowas wie ein Blog / Tagebuch? Dann setzt du besser eine
>> Zeitspalte und sortierst nach dieser. Du hast einen Titel? Oder
>> Kategorie? Dann wirst du früher oder später danach sortieren wollen.
> Okay, die Ausführungen machen Sinn. Aber ein Auto-Increment wird ja
> nicht zufällig vergeben, sondern halt pro Eintrag inkrementiert. Daher

Eine künstlicher Schlüssel wird per Definition beliebig vergeben. In der
Praxis mag dieser bei dir in der Reihenfolge erfolgen, wie du die
Eingaben vornimmst und dadurch bei einem Blog gemäss historischer Folge.
Du befindest dich mit deiner Lösung auf verdammt dünnem Eis.

> hat eine Sortierung danach eine historische Reihenfolge ohne dass es mir
> passieren könnte das plötzlich zwei gleiche auftauchen, oder nicht?
> Und ich gehe einfach mal davon aus, dass der Wertebereich groß genug
> gewählt ist..

Die Praxis richtet sich halt viel zu selten an die Theorie. Da du ein
Blog machst, kannst du wirklich die Zeiten verwenden. Wenn du nämlich
die DB einmal zügeln musst und vielleicht mit einer anderen Mergen
willst, wirst du auf Probleme stossen. Ist das zu weit hergeholt?
Denkste heute, ja. Alles schon da gehabt.

>> Vielleicht solltest du uns mehr über dein Projekt verraten?
> In der Tat handelt es sich um einen Blog auf der in der Signatur
> genannten Seite. Im Moment habe ich mal weder ein Archiv noch irgend
> eine Sortierung implementiert und daher böserweise nach
> auto-increment-IDs sortiert :-)
> Die Sortierung hol ich dann irgendwann nach, wenn es mal ein paar mehr
> Einträge werden.

Alles in allem: Gebastel.

Bye, Johannes

Re: Rücksprung-Seite berechnen

Daniel Fett schrieb:
> Johannes Vogel wrote:

>> Ach, du hast sowas wie ein Blog / Tagebuch? Dann setzt du besser eine
>> Zeitspalte und sortierst nach dieser. Du hast einen Titel? Oder
>> Kategorie? Dann wirst du früher oder später danach sortieren wollen.
>
> Okay, die Ausführungen machen Sinn. Aber ein Auto-Increment wird ja
> nicht zufällig vergeben, sondern halt pro Eintrag inkrementiert. Daher
> hat eine Sortierung danach eine historische Reihenfolge ohne dass es mir
> passieren könnte das plötzlich zwei gleiche auftauchen, oder nicht?
> Und ich gehe einfach mal davon aus, dass der Wertebereich groß genug
> gewählt ist..

Du kannst ausschließlich davon ausgehen, dass der Wert von DBMS vergeben
wird. Alles andere sind rein zufällige Coinzidenzen.

> In der Tat handelt es sich um einen Blog auf der in der Signatur
> genannten Seite. Im Moment habe ich mal weder ein Archiv noch irgend
> eine Sortierung implementiert und daher böserweise nach
> auto-increment-IDs sortiert :-)
> Die Sortierung hol ich dann irgendwann nach, wenn es mal ein paar mehr
> Einträge werden.

Füge einen created-Timestamp ein, solange du noch wenige Einträge hast!

MfG
Niels

--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · E-Commerce · Mambo Content Management |
------------------------------------------------------------ ----

Re: Rücksprung-Seite berechnen

Daniel Fett wrote:

> Okay, die Ausführungen machen Sinn. Aber ein Auto-Increment wird ja=20
> nicht zufällig vergeben, sondern halt pro Eintrag inkrementiert.=20

Nach Regeln, die das Backend definiert. ACID-Backends (InnoDB oder=20
richtige Datenbanken) werden zur Vermeindung von Duplikaten,=20
Race-Conditions und Deadlocks i.d.R. per Session einen Block von=20
Autoincrement-Werten reservieren, d.h. die ältere Session bekommt ggf. =

niederere Keys, selbst wenn sie später Comitted.

Loggt sich z.B. Redakteur A um 8:00 ins Redaktionssystem ein und geht=20
auf seinen Morgenschnaps in die Kantine, während Redakteur B, der sich =

um 8:10 angemeldet hat, die Nachricht vom Tod des Papstes eingibt, wird=20
die Sensationsnachricht von der Wiederauferstehung des Papstes, die der=20
angetrunkene A um 8:45 einstellt, bei einer Sortierung nach=20
Autoincrement als älter als die Todesnachricht erscheinen...

Gruß Sevo

Re: Rücksprung-Seite berechnen

Hartmut Holzgraefe wrote:

>> Lücken sind selbstredend üblich.
>=20
>=20
> das hängt vom Table-Handler ab, MyISAM zb. vergibt ohne
> Lücken,=20

Dafür hinterläßt es in den Situationen, in denen ACID-Backends Lü=
cken=20
produzieren, schlimmstenfalls einen toten Record, der korrekt behandelt=20
und gelöscht auch eine Lücke verursacht. Und es kann Deadlocks=20
verursachen...

Mit anderen Worten, unter MyISAM sind Autoincrement-Werte mit noch=20
größerer Vorsicht zu behandeln als unter InnoDB oder größeren Dat=
enbanken.

Gruß Sevo

Re: Rücksprung-Seite berechnen

Sevo Stille schrieb:
> Daniel Fett wrote:
>=20
>> Okay, die Ausführungen machen Sinn. Aber ein Auto-Increment wird ja =

>> nicht zufällig vergeben, sondern halt pro Eintrag inkrementiert.=20
>=20
>=20
> Nach Regeln, die das Backend definiert. ACID-Backends (InnoDB oder=20
> richtige Datenbanken) werden zur Vermeindung von Duplikaten,=20
> Race-Conditions und Deadlocks i.d.R. per Session einen Block von=20
> Autoincrement-Werten reservieren, d.h. die ältere Session bekommt ggf=
.
> niederere Keys, selbst wenn sie später Comitted.

Das ist etwas pauschal gesagt. ORACLE hantiert z.B. mit Sequences,=20
welche praktisch genau so funktionieren wie Auto-Increment. Und bevor=20
Sie die Dinger hatte, hat man Trigger verwendet um Auto-Increment zu=20
simulieren.

"Richtige Datenbanken" solltest du dann also auch ein paar aufzählen,=20
welche das von dir scheinbar bevorzugte Verhalten zeigen.

An deiner Kritik gegenüber der Sortierung nach Auto-Increment gibt es=20
natürlich nichts auszusetzen.

--=20
Gruss,
Fabian