[MySQL] Paging toepassing (next / previous links maken) *

[Verwijderd]

hoihoi
het volgende probleem:
ik heb in m'n DB een tabel, 'kalender' genaamd.

in deze tabel staan een aantal kolommen. Een van deze kolommen is 'datum' . Ik kan mijn tabel sorteren op 'datum' zodat de eerst komende datum bovenaan komt te staan. Tot hier gaat alles goed. Nu mijn tabel gesorteerd is op 'datum' wil ik dat mijn kalender_ID (= primaire sleutel, autoincrement) 'opnieuw geschreven' wordt.
wat ik bedoel:
ik heb:

code:

 kalender_ID     level       datum       tijdstip    
2                     1     2004-07-10  00:00:00    2004-07-10 21:58:49     
1                     1     2004-07-11  22:31:51    2004-07-10 21:57:10     
3                     1     2004-11-18  11:45:00    2004-07-11 16:58:30

ik wil:

code:

 kalender_ID     level       datum       tijdstip    
1                     1     2004-07-10  00:00:00    2004-07-10 21:58:49     
2                      1    2004-07-11  22:31:51    2004-07-10 21:57:10     
3                     1     2004-11-18  11:45:00    2004-07-11 16:58:30

dus: als de records gesorteerd staan op 'datum' wil ik kalender_ID aanpassen. Voor elk record moet het kalender_ID gelijk gesteld worden aan het rijnummer.

Dit alles is nodig, omdat de entry's NIET in correcte datumvolgorde ingevoegd worden, en er zullen ook entry's verdwijnen na verloop van tijd.
Mijn vraag is dus: welke query heb ik nodig?

[Dido]

De eerste vraag die in me opkomt: waarom zou je in hemelsnaam je primaire key willen wijzigen
Dat zou normaliter nergens voor nodig zijn, behalve eventueel bij eenmalige schoonmaakacties.

[Verwijderd]

omdat ik de primaire key gebruik !
ter verduidelijking:

ik heb onderaan de pagina 2 linkjes staan: vorige en volgende, zodat ik het vorige en het volgende bericht kan bekijken. om de plaats van vorige en volgende te bekomen, maak ik gebruik van kalender_ID (m'n primaire key dus) Maar als ik bij m'n primaire key 1 bijtel (volgende bericht) of 1 aftel (vorige bericht) krijg ik niet het chronologisch volgende resp. vorige bericht te zien, maar wel datgene met het volgende resp. vorige kalender_ID, wat niet noodzakelijk het chronologisch volgende bericht is...

[ Voor 14% gewijzigd door Verwijderd op 11-07-2004 18:46 . Reden: typo ]

[SH4D3H]

Waar heb je het over?

[Soultaker]

Het eenvoudigst lijkt mij de tabel in de juiste volgorde dumpen zonder id's, de tabel opnieuw aanmaken, en alles importeren. Zodra je de rijen verwijderd of verkeerd toevoegd zit je echer weer met hetzelfde probleem, enzij je bij het invoegen/verwijderen de id's aanpast.

[Verwijderd]

de tabel opnieuw maken is geen probleem, er staan enkel maar wat testwaarden in.
Het probleem is dat ik de tabel niet in de juiste volgorde KAN vullen, mede omdat er meerdere mensen dingen plannen, en in die tabel stoppen. Ze moeten echter wel gesorteerd op m'n site komen... gesorteerd op 'datum' that is...

[Verwijderd]

Vindt het een beetje een raar verhaal.
Jij wilt dus je Pri.Key aanpassen omdat deze niet klopt met de chronologische volgorde van de datum
Wil je deze update elke keer gaan uitvoeren nadat er een nieuw bericht is geplaatst ?
Denk dat het dan al snel een probleem wordt wat je in je code moet veranderen en niet in je database.
of snap ik je gewoon verkeerd.

[Verwijderd]

wel, je snapt het goed denk ik...
ik wil deze update idd elke keer als er een nieuwe entry geplaatst is, uitvoeren.
ik begrijp niet goed wat ik dan in m'n code zou moeten veranderen?
waar kan ik me anders op baseren dan op kalender_ID om te bepalen welk het chronologisch vorige en volgende element is?

[Verwijderd]

Ik denk dat je juist datum en tijd moet nemen om je volgende en vorige te bepalen. het maakt dan niet uit of je volgende id 8 of 212 is, je moet alleen met een select even oproepen wat de volgende is.
Een pri. key is juist een pri.key omdat hij uniek is en niet verandert.
ik zou dus gaan sorteren op datum en tijd en verwijzen naar het kalender_id die daar bij hoort.

[Verwijderd]

Alleen als je datum en tijd gaat gebruiken kan je beter gebruik maken van de functie
time(), daarmee kan je namelijk makkelijker mee rekenen dan een datum zoals 22/2/2007.

Kijk eens op http://nl3.php.net/time

[ Voor 4% gewijzigd door Verwijderd op 11-07-2004 20:21 ]

[SH4D3H]

Jep en time kun je als int makkelijk laten sorteren

[Bosmonster]

Als je enige probleem je vorige/vorige functies zijn dan kun je dat sowieso al veel makkelijker oplossen. Stuur bijvoorbeeld mee de huidige ID + of het volgende of vorige moet zijn. Bij de refresh maak je dan een eenvoudige query die eentje hoger ophaalt of lager.

Welke waarde de PK heeft maakt dus niks uit en zou ook niks uit mogen maken in je applicatie. Is dit wel zo dan is er iets serieus mis met je denkwijze/applicatie.

Verwijderd schreef op 11 juli 2004 @ 19:22:
Alleen als je datum en tijd gaat gebruiken kan je beter gebruik maken van de functie
time(), daarmee kan je namelijk makkelijker mee rekenen dan een datum zoals 22/2/2007.

Kijk eens op http://nl3.php.net/time

Dat is ook onzin. Je kunt vanuit MySQL eenvoudig een Date/time om laten zetten naar UNIX_TIMESTAMP. Daar hoef je (wederom) niet je data voor aan te passen, slechts je applicatie.

En sorteren doet MySQL net zo eenvoudig hoor.. er is niet voor niets een DATE/TIME/DATETIME format...

[ Voor 44% gewijzigd door Bosmonster op 11-07-2004 19:31 ]

[Verwijderd]

@ Bosmonster: daar heb je een punt...
wss heb ik dat zelf niet bedacht omdat ik pas 2 dagen bezig ben met SQL (je moet ergens beginnen)
welke eenvoudige query mag dat dan wel zijn? of heb je mss een site/link waar query's uitgelegd staan (soorten, syntaxen ed...?)

bedankt

[Verwijderd]

MySQL.com: http://www.mysql.com

PHPfreakz.nl tutorial: http://www.phpfreakz.nl/artikelen.php?aid=19

[ Voor 50% gewijzigd door Verwijderd op 11-07-2004 20:26 ]

[curry684]

curry684 schreef op 08 juli 2004 @ 14:52:
[...]

Je doet hier dus het ranzigste en foutste wat je met een database kunt doen: zogenaamde 'natural keys' gebruiken.

Onthoud de gouden regel: een primary key mag nooit of te nimmer enige betekenis hebben buiten een unieke identificatie van de regel!!!

Hieraan gerelateerd een quote van ik geloof Joe Celko wederom: "Once a user wants to know a primary key your application is in deep shit". Databasetabellen bestaan altijd uit 2 delen: het gedeelte dat relevant is voor de gebruiker, en het gedeelte van de DB (de primary/foreign keys). De gebruiker heeft nooit of te nimmer iets te zoeken in het gedeelte van de database!

Meer heb ik er niet echt aan toe te voegen

Tipje erbij trouwens: als vrijwel alle operaties op een tabel afhankelijk zijn van de tijdsvolgorde van een datestamp-kolom, leg een CLUSTERED primary key op die tabel. Maakt de toko hopeloos snel.

[whoami]

* whoami gaat naast curry staan.

Curry: ivm de clustered key; het gaat hier om MySQL. Ik weet niet of MySQL ook zoiets kent als een clustered key.
Trouwens, een clustered key op een datetime stamp kan wel goed zijn, mits die datetime stamp nadien niet meer (of nauwelijks) gewijzigd wordt.
De clustered key bepaalt nl. ook de fysieke opslag-volgorde, en de DB zou nogal veel bezig zijn met het 're-ordenen' van de records als die clustered key veel wijzigt. Niet leuk voor de performance dus bij UPDATE's van die column.

[Soultaker]

Ik denk dat ik het met Devinity eens ben:

Verwijderd schreef op 11 juli 2004 @ 19:14:
Ik denk dat je juist datum en tijd moet nemen om je volgende en vorige te bepalen. het maakt dan niet uit of je volgende id 8 of 212 is, je moet alleen met een select even oproepen wat de volgende is. Een pri. key is juist een pri.key omdat hij uniek is en niet verandert. ik zou dus gaan sorteren op datum en tijd en verwijzen naar het kalender_id die daar bij hoort.

Overigens hebben we dit recent nog besproken in dit topic:
[rml][ mysql+php] Efficiënt vorige/volgende links maken bij nieuws[/rml]
(Al moet ik toegeven dat dat topic nooit helemaal afgerond is, doordat de topic starter er niet meer in reageerde.)

curry684 schreef op 08 juli 2004 @ 14:52:
Onthoud de gouden regel: een primary key mag nooit of te nimmer enige betekenis hebben buiten een unieke identificatie van de regel!!!

Ik vind het grote onzin om dat als 'gouden regel' te poneren. Het gebruik van een ondoorzichtige id als primary key is slechts noodzakelijk als de gegevens uit zichzelf geen unieke combinatie kunnen vormen (denk bijvoorbeeld aan NAW-gegevens). Een primary key bestaat uit het deel van de gegevens van die rij die nodig is om de identiteit van de rij te bepalen. Het komt vaak voor dat er een zinnige, inhoudelijke primary key gebruikt kan worden.

Koppeltabellen gebruiken vaak bijvoorbeeld twee (of meer) foreign keys als primary key. In dat geval zijn hebben de velden waaruit een primary key bestaat een belangrijke betekenis. Bij authenticatiesystemen is het niet ongebruikelijk om een gebruiker te identificeren met zijn username en die username ook als primary key te gebruiken (en ja, dat betekent dat je de username niet kunt wijzigen!).

Eigenlijk komt jouw 'gouden regel' er op neer dat de primary key altijd een gegenereerde ID is. Als dat zo zou moeten zijn, waarom is het dan ueberhaupt mogelijk om te kiezen welke velden de primary key vormen? Dan kun je iedere tabel wel automatisch een ID-kolom geven en de primary key declaraties achterwege laten.

[Verwijderd]

De PK regel geldt inderdaad voornamelijk voor automatisch gegenereerde ID's, in dit geval met een oplopend nummer. Aangezien deze PK's geen enkele andere functie en/of betekenis hebben dan het uniek identificeren van een record moeten die ook niet gebruikt worden voor een end-user.

Daarnaast maakt de volgorde van PK's geen ruk uit, zolang een PK maar uniek is. (maar das neem ik aan gesneden koek )

[Soultaker]

DaJaN: was het je bedoeling om curry684 dom na te praten (meestal geen slecht idee, trouwens) of ben je simpelweg vergeten op mijn post in te gaan?

[marko77]

als je altijd de chronologisch volgende wilt hebben kan je bij het ophalen van de data voor weergave toch gewoon een sortering toepassen, dat heeft toch helemaal niets met de plaats van het record in de tabel te maken.

[Verwijderd]

Soultaker schreef op 11 juli 2004 @ 23:59:
DaJaN: was het je bedoeling om curry684 dom na te praten (meestal geen slecht idee, trouwens) of ben je simpelweg vergeten op mijn post in te gaan?

Als je mijn post leest dan geef ik curry684 juist ongelijk met zijn regel aangezien het inderdaad zo kan zijn dat een PK functioneel is. Bijvoorbeeld een Sofinummer. Dit kan als PK functioneren en tegelijkertijd ook voor een end-user belangrijk zijn. (hetzelfde punt als jij maakt)

Automatisch gegenereerde keys moeten echter geen betekenis hebben voor een end-user.

Overigens wordt er gemakshalve vaak gekozen voor een gegenereerde key aangezien composite keys met zo'n 6 atrributes niet handig zijn.

[ Voor 11% gewijzigd door Verwijderd op 12-07-2004 00:06 ]

[Soultaker]

Ah ja, mijn excuses; ik had het woordje deze als de gelezen en dat verschil is wel van essentieel belang voor je punt.

Verwijderd schreef op 12 juli 2004 @ 00:04:
Overigens wordt er gemakshalve vaak gekozen voor een gegenereerde key aangezien composite keys met zo'n 6 atrributes niet handig zijn.

Dat klopt; voor een gegeneerde key kiezen is vaak makkelijker dan nadenken over wat een rij uniek maakt. Toch kan die gemakzucht er ook voor zorgen dat de constraints op de database minder goed gedefinieerd zijn dan zou kunnen. Zie bijvoorbeeld de definitie van de prijzen-tabel in dit topic.

Aan de andere kant valt er wat voor te zeggen om elke rij een ondoorzichte key te geven, omdat het daarmee altijd mogelijk is om de layout van een tabel te wijzigen zonder dat dit gevolgen heeft voor de overigen tabellen. Als je de luxe hebt dat je eerst je databaseontwerp af kunt maken en er daarna pas gegevens in gaat stoppen, dan hoef je die optie natuurlijk niet per se open te houden.

[ Voor 95% gewijzigd door Soultaker op 12-07-2004 00:16 ]

[Verwijderd]

Soultaker schreef op 12 juli 2004 @ 00:10:
Ah ja, mijn excuses; ik had het woordje deze als de gelezen en dat verschil is wel van essentieel belang voor je punt.

No offence taken. Ik had me ook wel wat duidelijker uit mogen drukken.

[Verwijderd]

ola, dat gaat hier duidelijk boven mijn petje...
maar...
ik heb begrepen:
ik kan best het unieke ID niet gebruiken binnen een toepassing
dan vraag ik me af hoe ik een entry het beste aanspreek...?

maar dan een bedenking, gerelateerd aan mijn geval specifiek;
ik gebruik een aparte pagina om de inhoud (waar het om draait, de datum enz is maar 'opmaak') weer te geven. Naar deze pagina geef ik het kalender_ID mee, zodat ik enkel de record die door de websitebezoeker geselecteerd is ingelezen wordt, en weergegeven.
Ik lees dus maar 1 record in. Hoe kan ik dan bepalen welke record de datum net voor de huidige entry en de record met datum net na de huidige recod bevat? Ik lees tenslotte slechts 1 record in...
waar de gebruiker kan kiezen welke record hij wil bekijken, daar sorteer ik alles netjes op datum, maar in de tweede pagina gaat dat dus niet, er valt niets te sorteren, er is immers maar 1 recod ingelezen...

[bigbeng]

Ik zou zelf bij het volgende en vorige linkje het id van je huidige record meegeven en een code of het de volgende of vorige is (bijv record=1 of record=-1) die je probeert op te halen.

Dan haal je alle records op die groter dan of gelijk of kleiner dan of gelijk zijn qua datum t.o.v. het huidige record. Zoek het huidige record in je recordset, nog 1 stapje verder en dan heb je hem.

Het levert wat extra database load op en er zijn vast nog manieren om dat te beperken, maar het werkt wel altijd. En omdat het in dit geval op gebruikersinteractie neerkomt is het denk ik niet erg als er wat milliseconden verspild worden.

[gorgi_19]

Kleine topictitlechange, aangezien het hier niet echt meer gaat over die primary key wijzigen