nicht angemeldet
Fotogalerie - Vorherhiges und Nächstes Bild
Hi Forum,
ich versuche gerade eine Fotogalerie zu machen.
Die Übersichtsseite stellt auch keinerlei Problem dar. In der "Übersichtsseite.jsp" rufe ich mit einer Query alle Bilder die von ID=2 sind.
Mit LIMIT in der Query erstelle ich dann mehrere Seiten zum blättern, falls es zu viele Bilder sind.
Was mir gerade zum schaffen macht, wäre der Aufruf eines Bildes. "Bildseite.jsp". Ich übergebe die bildid in der Übersichtsseite.jsp und lasse das Bild in Bildseite.jsp anzeigen. Was ich nun auch realisiert habe, dass auf der Bildseite.jsp eine Verlinkung ist "Nächstes und Vorheriges" Bild.
Das habe ich vorläufig so realisiert, sobald ich bildid=1174074759810, datei, counter in der ersten Query aufrufe, lese ich in einer separaten zweiten Query die Zeilen counter+1 und counter-1.
Das ganze erscheint mir aber nicht so komfortabel. Vorallem, wenn man in der Übersichtsseite die Bilder nach "klicks" und "kommentare" sortieren will. Dann bringt die Spalte counter nichts. Meine Frage, wie ich in der Bildseite.jsp das vorherhige und nächste Bild von der Übersichtsseite zeigen könnte. Wie sollte hier die Datenbankstruktur etwa aussehen, bzw. welche Tipps und stichwörter für eine Query?
Grobe Tabelle: db_fotos
id bildid beschreibung klicks Kommentare datei counter
2 1174073349282 Bla Bla 4 0 ghh565hgfjhg.jpg 1
2 1174074124519 a Bla 3 0 hggh54545.jpg 2
2 1174074759810 a Bla 3 0 dfsew435ghf.jpg 3
2 1174074918644 a Bla 2 0 nbmhgjhggftzrzt.jpg 4
2 1174074951514 a Bla 3 0 ghjhkjhkj.jpg 5
-
Hi namenloser,
die SQL-Funktion LIMIT hat einen Nachteil, sie braucht lange bei einem hohen Offset,
weil sie ja erst mal durchzählen muss. Deshalb hole ich mit dem ersten SELECT erst
mal alle ID's und mit WHERE BildID IN (293, 159, 357, 951, 852) die eigentlichen Daten.
Dann verheddert man sich auch nicht, wenn die ID's nicht fortlaufend in der DB stehen.
Da der SELECT nach den ID's immer wieder auftaucht, behält ihn MySQL im Cache -> Performace!
HTHm.b.G. Rolf
-
yo,
Das habe ich vorläufig so realisiert, sobald ich bildid=1174074759810, datei, counter in der ersten Query aufrufe, lese ich in einer separaten zweiten Query die Zeilen counter+1 und counter-1.
dieser weg geht gar nicht, arbeite nicht mit der ID des bildes, sondern mit dem offset aus der LIMIT klausel bei gewünschter sortierung. den offset kannst du entprechend um 1 erhöhen oder erniedrigen
SELECT ....
FROM tabelle
ORDER BY _hier_deine_gewünschte_sortirung
LIMIT hier_offsetwert, 1Ilja
-
Hallo Ilja,
dieser weg geht gar nicht, arbeite nicht mit der ID des bildes, sondern
mit dem offset aus der LIMIT klausel bei gewünschter sortierung. den
offset kannst du entprechend um 1 erhöhen oder erniedrigenschlechte Idee!
Bei größer werdendem Offset geht die Datenbank in die Knie.
Z.B. Suchmaschinen klappern alle 5000 Treffer ab, da war der Server down.
Also muss etwas performateres her, und ID's sind performant.m.b.G. Rolf
-
yo,
Bei größer werdendem Offset geht die Datenbank in die Knie.
Z.B. Suchmaschinen klappern alle 5000 Treffer ab, da war der Server down.
Also muss etwas performateres her, und ID's sind performant.zum einen ist tuning, bzw. performance immer eine frage des bedarfs und der notwendigkeit.
zum anderen wie soll dann die sortierung funktionieren ?
Ilja
-
Hallo Ilja,
Bei größer werdendem Offset geht die Datenbank in die Knie.
Z.B. Suchmaschinen klappern alle 5000 Treffer ab, da war der Server down.
Also muss etwas performateres her, und ID's sind performant.
zum einen ist tuning, bzw. performance immer eine frage des bedarfs und der notwendigkeit.stimmt,
unter 1000 Items ist mein Weib schneller ;-)zum anderen wie soll dann die sortierung funktionieren ?
na-ja,
man kann ID's doch auch nach ISBN, Autor oder Mondphasen sortieren.
Wenn man dann mit IN () arbeitet, bleibt die WHERE-Klausel erhalten,
also nicht einfach wegschmeissen ;-)m.b.G. Rolf
-
-
-
den offset kannst du entprechend um 1 erhöhen oder erniedrigen
sorry für den unpassenden zwischenruf:
aber um ein offset zu erniedrigen, brauchst du ein sehr devotes offset ;)verringern würde besser passen
SCNR
-
-
Das habe ich vorläufig so realisiert, sobald ich bildid=1174074759810, datei, counter in der ersten Query aufrufe, lese ich in einer separaten zweiten Query die Zeilen counter+1 und counter-1.
wenn die bildid ein nummerischer wert ist, reicht ein größer- oder kleiner operator aus
SELECT bildid FROM db_fotos WHERE bildid > $aktuelle id
oder umgekehrt für das vorherige bildsolltest du keinen datensatz zurückbekommen, bist du bereits am ersten bild
du musst lediglich dafür sorgen, dass alle 3 abfragen (die des bildes und die des nächsten und vorherigen bildes) die selbe order-bedingung haben
etwas performanter als deine aktuelle lösung, du sparst dir dein zusätzliches feld in der datenbank und benötigst nur einen index auf die tabelle (die bildid)
sortierung "per hand" nach einem sorting-feld (in deinem fall counter) ist nicht bzw nur bedingt möglich, da du das aber ohnehin nach clicks usw sortieren willst, ist das nicht tragisch
-
Hey, super vielen Dank an alle die geantwortet haben.
SELECT bildid FROM db_fotos WHERE bildid > $aktuelle id
oder umgekehrt für das vorherige bildsolltest du keinen datensatz zurückbekommen, bist du bereits am ersten bild
ich arbeite dann am besten mit den bildid's direkt. danke auch für die restlichen tipps, mal schauen was sich da machen lässt.
grüße
undso
-