|
| Sorterings-system driller! Fra : Lasse Jensen |
Dato : 12-05-07 12:03 |
|
Hej proffer.
Jeg er ved at lave et nyhedssystem, og man kan sortere rækkefølgen af
nyhederne via tal.
Det vil dog ikke virke. Jeg kan ikke få den til at gøre det sådan, at
den nyeste nyhed har tallet 1, den anden nyeste 2 osv ...
Jeg har forsøgt med dette;
$db = mysql_connect("$mysqlHost", "$mysqlUser", "$mysqlPassword");
mysql_select_db("$mysqlDb", $db);
$query = mysql_query("SELECT sort FROM News ORDER BY sort ASC")
or die(mysql_error());
while ($data = mysql_fetch_array($query)) {
$sort = $data['sort'];
$sort++;
mysql_query("UPDATE News SET sort = '$sort' ORDER BY sort ASC")
or die(mysql_error());
}
Burde den så ikke hive 'sort' ud. lægge 1 til, og så opdatere den med
det nye tal?
Det gør den faktisk også. Men ikke helt korrekt.
I min INSERT er $sort = 1; ..
Nå man så poster en nyhed, burde 1 blive til 2 .. Det gør den.
Men så når man poster 3. gang, så burde 2 blive til 3, 1 til 2 og den
nye til 1.. Men i stedet bliver de gamle nyheder bare allesammen 3.Alså
så de 3 nyheder får tal, 1, 3 og 3, hvor det skulle have været 1, 2 og
3. Hvordan kan det være? Det virker som om den opdaterer det hele "ens"?
Det har drillet mig meget nu!
Så håber I kan hjælpe mig (:
På forhånd tak :)
Mvh. Lasse Jensen
| |
Bjarne Bue (12-05-2007)
| Kommentar Fra : Bjarne Bue |
Dato : 12-05-07 13:22 |
|
Lasse Jensen wrote:
> Hej proffer.
>
> Jeg er ved at lave et nyhedssystem, og man kan sortere rækkefølgen af
> nyhederne via tal.
>
> Det vil dog ikke virke. Jeg kan ikke få den til at gøre det sådan, at
> den nyeste nyhed har tallet 1, den anden nyeste 2 osv ...
>
> Jeg har forsøgt med dette;
[SNIP]
> while ($data = mysql_fetch_array($query)) {
>
> $sort = $data['sort'];
> $sort++;
>
> mysql_query("UPDATE News SET sort =
> '$sort' ORDER BY sort ASC") or die(mysql_error());
>
> }
Den tror jeg lige at du skal genoverveje. Hvis du gør ovenstående, så
vil du lave en UPDATE i databasen for hver eneste nyhed, hver gang du
tilføjer en ny. Så når du har 2000 nyheder, vil du lave 2000 UPDATEs for
at tilføje én nyhed. Det er ikke særlig effektivt.
Du kan lave det hele med en enkelt forespørgsel: UPDATE news SET sort =
sort + 1;
Men hvorfor vil du egentlig opdatere tallet for hver enkelt nyhed? Er
det for at kunne vise den seneste nyhed øverst? Så bruger du bare ORDER
BY id DESC (descending) i din forespørgsel, i modsætning til ASC
(ascending), som du bruger nu.
/ Bjarne
| |
Lasse Jensen (12-05-2007)
| Kommentar Fra : Lasse Jensen |
Dato : 12-05-07 13:46 |
|
Bjarne Bue skrev:
>
> Den tror jeg lige at du skal genoverveje. Hvis du gør ovenstående, så
> vil du lave en UPDATE i databasen for hver eneste nyhed, hver gang du
> tilføjer en ny. Så når du har 2000 nyheder, vil du lave 2000 UPDATEs for
> at tilføje én nyhed. Det er ikke særlig effektivt.
>
> Du kan lave det hele med en enkelt forespørgsel: UPDATE news SET sort =
> sort + 1;
Du siger noget der. Det er naturligvis rigtig nok. Det er ikke det mest
effektive. Men den metode du viser, er det ikke sammen princip? Så skal
den vel stadig opdatere alle nyhederne .. ?
Er der så ikke et andet alternativ, som har samme effekt?
>
> Men hvorfor vil du egentlig opdatere tallet for hver enkelt nyhed? Er
> det for at kunne vise den seneste nyhed øverst? Så bruger du bare ORDER
> BY id DESC (descending) i din forespørgsel, i modsætning til ASC
> (ascending), som du bruger nu.
>
Det er fordi er der skal laves et sorterings-system, sådan så man kan
trykke på en pil der peger op og ned, og så kan du rykke dem op og ned i
forhold til hinanden. Og det har jeg så valgt at bruge tal til. Så den
øverste nyhed er nummer 1. (Ikke nødvendigvis den nyeste), og så derned
efter.
Og samtidig skal tallet kunne ses i oversigten over nyheder, så tallet
skal også være i rækkefølge.
Hvis det bare var for at have dem i standard rækkefølge, ville man jo
naturligvis bare benytte sig af ASC og DESC, som du siger.
Mvh. Lasse Jensen
| |
Geert Lund (13-05-2007)
| Kommentar Fra : Geert Lund |
Dato : 13-05-07 10:39 |
|
Lasse Jensen wrote:
>> Du kan lave det hele med en enkelt forespørgsel: UPDATE news SET sort
>> = sort + 1;
>
> Du siger noget der. Det er naturligvis rigtig nok. Det er ikke det mest
> effektive. Men den metode du viser, er det ikke sammen princip? Så skal
> den vel stadig opdatere alle nyhederne .. ?
>
> Er der så ikke et andet alternativ, som har samme effekt?
Da din rutine jo åbenbart fejler - kan man sige - at det alternativ som
Bjarne skriver - måske ikke er et alternativ med samme effekt.
Der er ingen tvivl om at med det du ønsker - virker
UPDATE news SET sort = sort + 1
som mere korrekt - dette vil ikke give uhensigtsmæsige problemer og
fungere perfekt i forhold til det du ønsker.
Du bør dog nok i samme omgang overveje - hvad der sker når man
sletter/fjerner indlæg osv. - hvordan skal din nummerrækkefølge så
defineres i forhold til at du gerne vil udlæse tallet i din oversigt (jf.):
> Og samtidig skal tallet kunne ses i oversigten over nyheder, så
> tallet skal også være i rækkefølge.
--
Med venlig hilsen
Geert Lund,
www.GLD.dk
| |
Bjarne Bue (13-05-2007)
| Kommentar Fra : Bjarne Bue |
Dato : 13-05-07 12:10 |
|
Lasse Jensen wrote:
> Bjarne Bue skrev:
>>
>> Den tror jeg lige at du skal genoverveje. Hvis du gør ovenstående, så
>> vil du lave en UPDATE i databasen for hver eneste nyhed, hver gang du
>> tilføjer en ny. Så når du har 2000 nyheder, vil du lave 2000 UPDATEs
>> for at tilføje én nyhed. Det er ikke særlig effektivt.
>>
>> Du kan lave det hele med en enkelt forespørgsel: UPDATE news SET sort
>> = sort + 1;
>
> Du siger noget der. Det er naturligvis rigtig nok. Det er ikke det mest
> effektive. Men den metode du viser, er det ikke sammen princip? Så skal
> den vel stadig opdatere alle nyhederne .. ?
Det er rigtigt at alle nyheder stadig bliver opdateret på denne måde.
Men forskellen på
while (mysql_fetch_array($x) {
$result = mysql_query("UPDATE news SET sort=$y WHERE id=$z");
}
og
$result = mysql_query("UPDATE news SET sort = sort + 1");
er, at på den første måde kontaktes databasen én gang for hver nyhed,
der sendes en forespørgsel og returneres et resultat. På den anden måde
kontaktes databasen kun én gang i alt, der sendes kun én forespørgsel,
og alle opdateringer sker i ét hug. Det vil være mere effektivt, men
stadig ikke nogen fantastisk måde at gøre tingene på.
> Er der så ikke et andet alternativ, som har samme effekt?
Til dit sorteringssystem tror jeg, at jeg ville lave en form for Linked
List, hvor hvert element peger på det foregående i sorteringsrækkefølgen. Fx
| id | prev_id |
| 1 | 3 |
| 2 | 5 |
| 3 | - |
| 4 | 1 |
| 5 | 4 |
Ovenstående vil give denne rækkefølge: 3, 1, 4, 5, 2. På den måde skal
du kun opdatere to nyheder, når du ændrer sorteringen, nemlig den nyhed
du flytter (eller indsætter), og den nyhed, der tidligere havde den
plads, du flytter til.
Det er ikke noget jeg har en færdig løsning på, og jeg har ikke tænkt
ret meget over, hvordan man kan trække den rigtige sorteringsrækkefølge
ud af databasen. Men du kan finde masser af teori om Linked Lists via en
Google-søgning.
>> Men hvorfor vil du egentlig opdatere tallet for hver enkelt nyhed? Er
>> det for at kunne vise den seneste nyhed øverst? Så bruger du bare
>> ORDER BY id DESC (descending) i din forespørgsel, i modsætning til ASC
>> (ascending), som du bruger nu.
>>
>
> Det er fordi er der skal laves et sorterings-system, sådan så man kan
> trykke på en pil der peger op og ned, og så kan du rykke dem op og ned i
> forhold til hinanden. Og det har jeg så valgt at bruge tal til. Så den
> øverste nyhed er nummer 1. (Ikke nødvendigvis den nyeste), og så derned
> efter.
>
> Og samtidig skal tallet kunne ses i oversigten over nyheder, så tallet
> skal også være i rækkefølge.
>
> Hvis det bare var for at have dem i standard rækkefølge, ville man jo
> naturligvis bare benytte sig af ASC og DESC, som du siger.
>
> Mvh. Lasse Jensen
/ Bjarne
| |
Michael Rasmussen (13-05-2007)
| Kommentar Fra : Michael Rasmussen |
Dato : 13-05-07 12:42 |
|
On Sun, 13 May 2007 13:10:04 +0200
Bjarne Bue <spam@spaceball.dk> wrote:
>
> Til dit sorteringssystem tror jeg, at jeg ville lave en form for
> Linked List, hvor hvert element peger på det foregående i
> sorteringsrækkefølgen. Fx
>
> | id | prev_id |
> | 1 | 3 |
> | 2 | 5 |
> | 3 | - |
> | 4 | 1 |
> | 5 | 4 |
>
Ovenstående refererer til det, der i relationel teori hedder en
ordningsrelation. Der findes utallige eksempler på implementation af en
sådan. Anvender du MySQL-5.x kan du lave det som en kombination
af en trigger og en stored procedure.
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
A computer is like air conditioning: it becomes useless when you open
windows.
| |
Michael Zedeler (13-05-2007)
| Kommentar Fra : Michael Zedeler |
Dato : 13-05-07 20:07 |
|
On Sun, 2007-05-13 at 13:10 +0200, Bjarne Bue wrote:
> Lasse Jensen wrote:
> > Er der så ikke et andet alternativ, som har samme effekt?
>
> Til dit sorteringssystem tror jeg, at jeg ville lave en form for Linked
> List, hvor hvert element peger på det foregående i sorteringsrækkefølgen. Fx
>
> | id | prev_id |
> | 1 | 3 |
> | 2 | 5 |
> | 3 | - |
> | 4 | 1 |
> | 5 | 4 |
>
> Ovenstående vil give denne rækkefølge: 3, 1, 4, 5, 2. På den måde skal
> du kun opdatere to nyheder, når du ændrer sorteringen, nemlig den nyhed
> du flytter (eller indsætter), og den nyhed, der tidligere havde den
> plads, du flytter til.
Med mindre Lasse skal bruge et træ og ikke en liste, er det ikke nogen god idé.
Hvordan skal man forstå dette her:
id | prev_id
1 | NULL
2 | 1
3 | 1
Det er jo fordi du med prev_id indfører en mange til mange-relation som
dermed kan blive (mis)brugt til at repræsentere et træ. Man kan
selvfølgelig overveje at sætte et unique constraint på prev_id, men det
mest almindelige er at man har et sorteringsfelt, som kun indikerer i
hvilken rækkefølge en gruppe af artikler skal ordnes.
Problemet med din liste er (også) at det er møj besværligt at hive
emnerne ud af den i den rigtige rækkefølge uden at bruge rekursive
selects, som svjv kun er understøttet af Oracle.
Mvh. Michael.
| |
Lasse Jensen (17-05-2007)
| Kommentar Fra : Lasse Jensen |
Dato : 17-05-07 11:38 |
|
Ja der er nok af muligheder.
Jeg kigger på det :)
Tak for svarene (:
Mvh. Lasse Jensen
| |
|
|