mboost-dp1
PHP: Inddel downloads i sider
Jeg roder med en download-side til butiksguiden.net og på grund af lidt grafikproblemer med enkelte af de tilgængelige designs (tænkte mig åbenbart ikke om da jeg lavede koden) kan jeg ikke have en side der fortsætter i det nærmest uendelige. Derfor vil jeg gerne dele dem op i sider á 10 downloads.
Den vigtige del af koden kan ses her
http://www.butiksguiden.net/Download.phps
Havde overvejet noget med at funktionen 'lavdownload' holder tal på de downloads den laver. Der skal så være en side-variabel der fortæller hvilken side man vil se, og så echoer 'lavdownload' den pågældende download, hvis den hører til siden.
Altså noget i retning af denne pseudo-slamkode (som sikkert ikke virker)
Et andet alternativ ville være at lade 'lavdownload' smide dem ind i et array og køre det gennem til sidst.
Men hvad er bedst, og vigtigst af alt - er der nogen med den nødvendige viden der har lyst til at kode noget :)
Den vigtige del af koden kan ses her
http://www.butiksguiden.net/Download.phps
Havde overvejet noget med at funktionen 'lavdownload' holder tal på de downloads den laver. Der skal så være en side-variabel der fortæller hvilken side man vil se, og så echoer 'lavdownload' den pågældende download, hvis den hører til siden.
Altså noget i retning af denne pseudo-slamkode (som sikkert ikke virker)
$i = 0;
$side = 2; //Vi vil se side 2, fra $_GET['var']
$fra = ($side - 1) * 10;
$til = $side * 10;
if ($i >= $fra) && ($i < $til) {
echo pågældende download;
} else {
kan det sgu være lige meget;
}
$i++;
Et andet alternativ ville være at lade 'lavdownload' smide dem ind i et array og køre det gennem til sidst.
Men hvad er bedst, og vigtigst af alt - er der nogen med den nødvendige viden der har lyst til at kode noget :)
Hvad med at smide download links'ne, info etc. ind i en database, og så lade den køre et check på id for at checke antal af downloads, dernæst generere antal af sider udfra formlen ([ANTAL ID]/10) rundet op = antal sider og et array på ID 1-10 for info.
Så vil du også kunne lave tricks som at add'e til 1 til en row hver gang der klikkes så man kan se hvor mange gange jeres ting hentes etc.
En sådan side kan med stor fordel caches hvis der ikke er nye uploads alt for tit. Evt. laves næsten statisk og så kører du selv scriptet de gange der opdates etc.
Så vil du også kunne lave tricks som at add'e til 1 til en row hver gang der klikkes så man kan se hvor mange gange jeres ting hentes etc.
En sådan side kan med stor fordel caches hvis der ikke er nye uploads alt for tit. Evt. laves næsten statisk og så kører du selv scriptet de gange der opdates etc.
Jeg tæller skam allerede op i databasen, det er bare i en anden fil (download.php som ikke har noget med denne at gøre) der sørger for at smide en fil uden for webscope videre til brugeren :)
Men ja, det er nok det smarteste at gøre, at smide det hele over i en database, da det jo som du skriver er lidt nemmere at jonglere med og sætte kritterier for.
Men det med cachingen kender jeg godt nok intet til, hvordan havde du forestillet dig det skulle foregå? Ud fra antal besøgende kan jeg dog ikke rigtig se nødvendigheden.
Men ja, det er nok det smarteste at gøre, at smide det hele over i en database, da det jo som du skriver er lidt nemmere at jonglere med og sætte kritterier for.
Men det med cachingen kender jeg godt nok intet til, hvordan havde du forestillet dig det skulle foregå? Ud fra antal besøgende kan jeg dog ikke rigtig se nødvendigheden.
#3: Det kan gøres på flere måde - den mest optimale løsning er at installere noget php caching på serveren.
En work-around, er at du kører et script der laver de statiske sider hvergang der tilføjes noget til download sektionen.
Men det er langt fra et must, er bare en rar feature - især hvis php eller db serveren er lidt overworked.
En work-around, er at du kører et script der laver de statiske sider hvergang der tilføjes noget til download sektionen.
Men det er langt fra et must, er bare en rar feature - især hvis php eller db serveren er lidt overworked.
Sidder faktisk pt. og laver det samme på en af mine sider, og jeg valgte også databasemodellen, da jeg mener den er klart nemmest at have med at gøre, og man kan bruge databasen til mange andre ting, som f.eks. at tælle antal download.
Har i den forbindelse et spørgsmål det kunne være fedt om en af jer kunne svare på. (håber det er ok at stille det her)
Ved i hvordan man omdøber en fil når en person vælger at downloade den... eks.
fil på server: 15464216576451.pdf
når personen trykker på linket til download foreslå browseren at gemme filen som budget_feb_2005.pdf
Jeg har ledt over alt på php.net men kan ikke finde funktionen, og jeg ved at den eksistere!
Har i den forbindelse et spørgsmål det kunne være fedt om en af jer kunne svare på. (håber det er ok at stille det her)
Ved i hvordan man omdøber en fil når en person vælger at downloade den... eks.
fil på server: 15464216576451.pdf
når personen trykker på linket til download foreslå browseren at gemme filen som budget_feb_2005.pdf
Jeg har ledt over alt på php.net men kan ikke finde funktionen, og jeg ved at den eksistere!
Disse bruger jeg
header("Content-Type: $strMimeType; name=\"$strBaseName\"");
header("Content-Disposition: $strDisposition; filename=\"$strBaseName\"");
hvor $strBaseName sætter navnet, så de ikke får en "index.php.avi" i hovedet
Jeg ved ikke hvilken af dem der rent faktisk gør arbejdet, men det kan du jo passende undersøge :)
header("Content-Type: $strMimeType; name=\"$strBaseName\"");
header("Content-Disposition: $strDisposition; filename=\"$strBaseName\"");
hvor $strBaseName sætter navnet, så de ikke får en "index.php.avi" i hovedet
Jeg ved ikke hvilken af dem der rent faktisk gør arbejdet, men det kan du jo passende undersøge :)
#6 - Wolly:
Du kan ikke altid bruge den korrekte mime-type, da IE (5 og 5.5 svjh) (igen igen) totalt ignorer header instruktioner om at hente filen og ikke vise den, hvis IE kan vise filtypen. En quick-fix er at tjekke om det er IE og hvis det er så sende application/x-download som mime-type (mime-typen kan sådan set være "familie/dinmor" men den anden er nok lidt bedre :-)
Du kan ikke altid bruge den korrekte mime-type, da IE (5 og 5.5 svjh) (igen igen) totalt ignorer header instruktioner om at hente filen og ikke vise den, hvis IE kan vise filtypen. En quick-fix er at tjekke om det er IE og hvis det er så sende application/x-download som mime-type (mime-typen kan sådan set være "familie/dinmor" men den anden er nok lidt bedre :-)
Sådan :)
http://www.butiksguiden.net/index.php?s=Download
Tak til dem der hjalp
Måske man skulle lave så brugeren kan sortere efter antal downloads og ting. Selv om det nok ville dække min lyst mere end et reelt behov :)
http://www.butiksguiden.net/index.php?s=Download
Tak til dem der hjalp
Måske man skulle lave så brugeren kan sortere efter antal downloads og ting. Selv om det nok ville dække min lyst mere end et reelt behov :)
Selv om det nok ville dække min lyst mere end et reelt behov :)
Sådan er det næsten altid med de sider/programmer jeg laver :)
En mere generel løsning til dit problem med at dele indholdet op i sider, ville være at bruge SQL key word'et "LIMIT X,Y" det begrænser resultatet til Y resultater, startende fra resultat X.
Pseudo kode:
bruger jeg selv rigtigt meget :)
Pseudo kode:
$perpage=10; # vi 10 ting per side
$page=_GET["p"];
$SQL="SELECT * FROM downloadtabel WHERE $betingelse ORDER BY $sortersefter $UPDOWN"; # sql statement der viser ALLE de ting du vil have, med den sortering der skal være osv..
# $betingelsen er det brugeren evt søger efter
# $sorterefter er f.eks. størrelse el. lign
# $UPDOWN er hhv ASC DESC afhængigt af om resultaterne skal starte med største eller mindste værdi
$SQL.= "LIMIT ".($perpage*$page).",".$perpage";
$results = do_sql($SQL);
foreach $result in $results
{
vis_et_enkelt_resultat_på_en_smart_måde($result);
}
bruger jeg selv rigtigt meget :)
#10: Som du kan se i #8 har jeg allerede løst det (ved hjælp af database, nogenlunde samme måde som du gør det på). Bare knap så kønt
http://pastebin.com/276098
#9: Ja, det er jo sådan set også en god ting, hvis der ikke er mere at lave. Så kan man da lige så godt lave noget nytteløst og lære af det :)
Nu ved jeg bare ikke hvad jeg ellers skal lave på siden.. Ud over dette
http://pastebin.com/276098
#9: Ja, det er jo sådan set også en god ting, hvis der ikke er mere at lave. Så kan man da lige så godt lave noget nytteløst og lære af det :)
Nu ved jeg bare ikke hvad jeg ellers skal lave på siden.. Ud over dette
Ved ikke om det kan betale sig at fortsætte i denne tråd, egentlig burde jeg lave en ny.. Men anyway, hvilken af disse synes I bedst om?
http://butiksguiden.net/UseBB/
http://butiksguiden.net/minibb/
http://butiksguiden.net/mercuryboard/
Selv er jeg til minibb da det er ekstremt enkelt at se på, kender I andre små (gratis) php fora man kan bruge? Og det skal ikke være et monstrøst forum, så ingen phpbb eller lignende tak :)
http://butiksguiden.net/UseBB/
http://butiksguiden.net/minibb/
http://butiksguiden.net/mercuryboard/
Selv er jeg til minibb da det er ekstremt enkelt at se på, kender I andre små (gratis) php fora man kan bruge? Og det skal ikke være et monstrøst forum, så ingen phpbb eller lignende tak :)
#14 Ronson:
Jeg er også mest til miniBB, da det udover at have et simpelt design også er ret funktionelt, og så er det klart et plus, at det på trods af funktioner er brugervenligt.
Det er endvidere en fordel, at et så simpelt design let kan integreres i en komplet side uden, at det nødvendigvis er et krav at oprette en ny skabelon til systemet. Farvejusteringer o. lign. vil egentlig være nok.
Men det kommer vel an på behovet? Hvad skal forummet anvendes til?
Jeg er også mest til miniBB, da det udover at have et simpelt design også er ret funktionelt, og så er det klart et plus, at det på trods af funktioner er brugervenligt.
Det er endvidere en fordel, at et så simpelt design let kan integreres i en komplet side uden, at det nødvendigvis er et krav at oprette en ny skabelon til systemet. Farvejusteringer o. lign. vil egentlig være nok.
Men det kommer vel an på behovet? Hvad skal forummet anvendes til?
Det skal kun anvendes til hurtige tilbagemeldinger fra brugere, ingen vilde diskussioner eller noget. Desværre er der ikke umiddelbart mulighed for at angive et navn når man er anonym i minibb (man hedder altså altid "Anonym" når man ikke er logget ind), hvilket der er mulighed for i UseBB.
Det er faktisk et krav at man skal kunne oprette/svare tråde uden login, så mercuryboard er nok ikke et alternativ længere.
Jeg tror ikke umiddelbart at den skal integreres i siden, da det halve af vores designs ikke vil kunne rumme det i bredden.
Så jeg er splittet mellem minibb (som mangler muligheden for at kunne angive navn, men allerede er oversat til dansk) og UseBB (der virker lidt (for) popsmart og som jeg skal til at oversætte, men som har alle funktionerne)
Det er faktisk et krav at man skal kunne oprette/svare tråde uden login, så mercuryboard er nok ikke et alternativ længere.
Jeg tror ikke umiddelbart at den skal integreres i siden, da det halve af vores designs ikke vil kunne rumme det i bredden.
Så jeg er splittet mellem minibb (som mangler muligheden for at kunne angive navn, men allerede er oversat til dansk) og UseBB (der virker lidt (for) popsmart og som jeg skal til at oversætte, men som har alle funktionerne)
Som #15 siger kommer det meget an paa hvad du vil med det - umiddelbart vil jeg sige at det kunne give lige saa god mening at lave det selv.
Kraever ikke saa meget at koble indlaeg til en traad eller en artikel eller en download.
Er vel mest admin delen der kan kraeve lidt.
Kraever ikke saa meget at koble indlaeg til en traad eller en artikel eller en download.
Er vel mest admin delen der kan kraeve lidt.
Kommer helt an paa hvad du vil - som jeg forstaar dig, vil du have et slags forum og mulighed for at kommenterer artikel og download posts.
I saa fald ville jeg lave foelgende tabeller:
User: id, name, (email), pass
Type: id, typename, evt. modifier for type (kunne vaere en class eller en variabel du kan bruge til noget).
Thread: id, name, datetimestamp, userid (den user som starter den - kan vaere tom til artikel og download comments).
Comment: id, threadid, userid, datetimestamp, sequencenr. (nr. post i traaden - vil evt. ogsaa kunne sortes paa datetimestamp eller id, men er rart at have nevertheless imho).
Evt. tillaeg:
Profile: id, userid, email, im-a, im-b, signature, town osv.
Dette er lige fra hovedet og er altsaa ikke noedvendigvis saerligt optimeret - men det ville vaere mit udgangspunkt anyway - profile kunne sikkert smaekkes i user tabellen, men personligt foretraekker jeg mindre tabeller end faa store idet select statements hurtigt kan blive kringlet i visse tilfaelde).
I saa fald ville jeg lave foelgende tabeller:
User: id, name, (email), pass
Type: id, typename, evt. modifier for type (kunne vaere en class eller en variabel du kan bruge til noget).
Thread: id, name, datetimestamp, userid (den user som starter den - kan vaere tom til artikel og download comments).
Comment: id, threadid, userid, datetimestamp, sequencenr. (nr. post i traaden - vil evt. ogsaa kunne sortes paa datetimestamp eller id, men er rart at have nevertheless imho).
Evt. tillaeg:
Profile: id, userid, email, im-a, im-b, signature, town osv.
Dette er lige fra hovedet og er altsaa ikke noedvendigvis saerligt optimeret - men det ville vaere mit udgangspunkt anyway - profile kunne sikkert smaekkes i user tabellen, men personligt foretraekker jeg mindre tabeller end faa store idet select statements hurtigt kan blive kringlet i visse tilfaelde).
Jeg forstår ikke helt Type men ellers lyder det ikke dumt (og profil og user bliver slået sammen, da mit ego er ligefrem proportionelt med select-statements størrelser).
Lige den 'sequencenr' synes jeg dog lyder lidt skør, da det jo teknisk set vil være dobbeltarbejde, hvis timestamp er fejlsikker :)
Lige den 'sequencenr' synes jeg dog lyder lidt skør, da det jo teknisk set vil være dobbeltarbejde, hvis timestamp er fejlsikker :)
#19 Deternal:
Til simpelt brug, så kan man vel sagtens nøjes med følgende:
Users (uid, username, pwd)
Threads (tid, uid, parent, timestamp, text)
Brugertabellen giver vist sig selv, og kan selvfølgelig udvides efter behov, som du også beskriver. Med den overskuelige størrelse, som siden har, så er der vist ingen grund til at dele det op til selvstændige tabeller, selvom flere felter er valgfri.
Tabellen til tråde er også ret lige til. Autonummereringen (tid) bruges både til reference og til sortering. 'Parent' bør i dette tilfælde være et tekstfelt, så den øverste tråd refererer til "a34" (for artikel 34) eller "r12" (for review 12) - alle underliggende tråde referer blot til nummeret.
Man kan naturligvis lave 'parent' pænere ved at dele det op i seperate felter, men egentlig er der ingen fordele i dette til det brug, som Ronson beskriver - i mine øjne.
Til simpelt brug, så kan man vel sagtens nøjes med følgende:
Users (uid, username, pwd)
Threads (tid, uid, parent, timestamp, text)
Brugertabellen giver vist sig selv, og kan selvfølgelig udvides efter behov, som du også beskriver. Med den overskuelige størrelse, som siden har, så er der vist ingen grund til at dele det op til selvstændige tabeller, selvom flere felter er valgfri.
Tabellen til tråde er også ret lige til. Autonummereringen (tid) bruges både til reference og til sortering. 'Parent' bør i dette tilfælde være et tekstfelt, så den øverste tråd refererer til "a34" (for artikel 34) eller "r12" (for review 12) - alle underliggende tråde referer blot til nummeret.
Man kan naturligvis lave 'parent' pænere ved at dele det op i seperate felter, men egentlig er der ingen fordele i dette til det brug, som Ronson beskriver - i mine øjne.
#20: Er nok mest til traedede diskussioner - men hvis ens site traffik goer at man kan forestille sig at folk poster paa samme tidspunkt kan det godt give et problem - i praksis burde man dog kunne sorte efter id.
#21: Tjoeh, som sagt foretraekker jeg selv flere tabeller frem for faa store. Mht. at putte comment og thread i samme tabel er det en daarlig ide udfra et db optimeringssynspunkt. Men du har ret i at fra et scripting synspunkt er din model nok nemmere :>
#21: Tjoeh, som sagt foretraekker jeg selv flere tabeller frem for faa store. Mht. at putte comment og thread i samme tabel er det en daarlig ide udfra et db optimeringssynspunkt. Men du har ret i at fra et scripting synspunkt er din model nok nemmere :>
Tror hellere jeg må specificere det helt præcist nu.
Deternal gav mig (i #17) den gode ide at lave tråde specifikt til hver download. Det skal, hvis jeg evner det, være sådan at de både skal optræde i deres egen kategori i forummet, og man skal kunne skrive/læse på download-siden.
Ved hver download skal der altså være en diskutér-knap, der lister downloaden øverst, og alle kommentarer nedenunder. Samtidig skal man i forummet kunne læse/skrive i samme tråd (men man skal selvfølgelig ikke kunne oprette tråde i den kategori, da der kun må være én pr download). Det lyder vel rimelig fornuftigt?
På chipsguidens forum har jeg login-tabellen:
loginid, status, brugernavn, kodeord, email, hjemmeside
og forum-tabellen:
postid, traadid, brugerid, emne, tekst, status, dato
hvor status bestemmer om det er en tråd eller svar. Når man så skal slette en hel tråd er det jo blot DELETE FROM forum WHERE traadid='blah'.
Den model vil jeg jo kunne genbruge mere eller mindre, hvis jeg læser jeres indlæg rigtigt. Der skal bare lige ændres lidt datatyper (man er vel blevet klogere). Så mangler jeg blot en forklaring af hvad Deternal vil med "type" :)
#21: Hvad mener du med referering til "Autonummereringen (tid)"? Snakker vi her timestamp, eller, som jeg håber, auto_increment af id? Egentlig er sortering efter timestamp mere logisk i mit hoved, da id intet har at sige i forhold til indlægget (og kan ændres uden at indlægget på en eller anden måde ændrer mening) - modsat timestamp.
#22: Altså hvis folk poster samtidig (og det skal jo være i samme sekund) så betyder det at siden begynder at have for mange besøgende, det sker jo næppe.
Deternal gav mig (i #17) den gode ide at lave tråde specifikt til hver download. Det skal, hvis jeg evner det, være sådan at de både skal optræde i deres egen kategori i forummet, og man skal kunne skrive/læse på download-siden.
Ved hver download skal der altså være en diskutér-knap, der lister downloaden øverst, og alle kommentarer nedenunder. Samtidig skal man i forummet kunne læse/skrive i samme tråd (men man skal selvfølgelig ikke kunne oprette tråde i den kategori, da der kun må være én pr download). Det lyder vel rimelig fornuftigt?
På chipsguidens forum har jeg login-tabellen:
loginid, status, brugernavn, kodeord, email, hjemmeside
og forum-tabellen:
postid, traadid, brugerid, emne, tekst, status, dato
hvor status bestemmer om det er en tråd eller svar. Når man så skal slette en hel tråd er det jo blot DELETE FROM forum WHERE traadid='blah'.
Den model vil jeg jo kunne genbruge mere eller mindre, hvis jeg læser jeres indlæg rigtigt. Der skal bare lige ændres lidt datatyper (man er vel blevet klogere). Så mangler jeg blot en forklaring af hvad Deternal vil med "type" :)
#21: Hvad mener du med referering til "Autonummereringen (tid)"? Snakker vi her timestamp, eller, som jeg håber, auto_increment af id? Egentlig er sortering efter timestamp mere logisk i mit hoved, da id intet har at sige i forhold til indlægget (og kan ændres uden at indlægget på en eller anden måde ændrer mening) - modsat timestamp.
#22: Altså hvis folk poster samtidig (og det skal jo være i samme sekund) så betyder det at siden begynder at have for mange besøgende, det sker jo næppe.
#22 Deternal:
Vi er vist fuldstændigt enige generelt ;)
#23 Ronson:
Feltet 'tid' (thread id) er et tal ('auto_increment' eller 'integer identity'), og det er derfor låst, hvorfor det ikke kan ændres. Jeg har egentlig den opfattelse, at det er hurtigere at sortere efter tiden pga. feltets størrelse og netop, fordi det er det første felt i rækken, og som følge af, at rækkerne indsættes systematisk i forhold til id (men også i forhold til tidspunktet).
Dit tabeldesign er egentlig ganske udemærket, og det behøver ikke at udvides yderligere. Fordelen ved det valg er nok også, at du allerede kan genbruge en bunke kode, og det er altid et godt udgangspunkt, så kan optimeringer og løbende forbedringer ske med baggrund i noget gennemtestet.
Jeg er ret sikker på, at Deternals 'type' skal bruges til at definere, hvilken tråd der hører til de forskellige ting (downloads, artikler, debat o. lign.) Det kan du derfor let erstatte af dit 'traadid', hvor dette er bygget direkte ind i din primære tabel.
Vi er vist fuldstændigt enige generelt ;)
#23 Ronson:
Feltet 'tid' (thread id) er et tal ('auto_increment' eller 'integer identity'), og det er derfor låst, hvorfor det ikke kan ændres. Jeg har egentlig den opfattelse, at det er hurtigere at sortere efter tiden pga. feltets størrelse og netop, fordi det er det første felt i rækken, og som følge af, at rækkerne indsættes systematisk i forhold til id (men også i forhold til tidspunktet).
Dit tabeldesign er egentlig ganske udemærket, og det behøver ikke at udvides yderligere. Fordelen ved det valg er nok også, at du allerede kan genbruge en bunke kode, og det er altid et godt udgangspunkt, så kan optimeringer og løbende forbedringer ske med baggrund i noget gennemtestet.
Jeg er ret sikker på, at Deternals 'type' skal bruges til at definere, hvilken tråd der hører til de forskellige ting (downloads, artikler, debat o. lign.) Det kan du derfor let erstatte af dit 'traadid', hvor dette er bygget direkte ind i din primære tabel.
Ideen med type er at lave en databasebaseret variabel som kan bruges saaledes naar man f.eks. via forum'et gaar ind paa en traad om downloaden "newage.avi.zip" saa siger type at thread er type download, og saa vil koden smide et link til download siden ind oeverst i traaden.
Mao. skal man ikke ind et sted og definere at thread id x, y, z og t er artikel og n,m,b er type download og resten er type discussion - det ved man allerede idet typen er defineret i tabellen og dermed hentes som variabel som ens kode kan parse.
Haaber det gav mening :>
Kiggede lige paa mit indlaeg igen og kan see at typeid ikke er i min thread tabel saa kan godt forstaa hvis der er lidt undren over det.
Igen vil det skabe ekstra redundans i commentdelen at have det ekstra punkt der - jf. mit db optimeringsargument :P
Mao. skal man ikke ind et sted og definere at thread id x, y, z og t er artikel og n,m,b er type download og resten er type discussion - det ved man allerede idet typen er defineret i tabellen og dermed hentes som variabel som ens kode kan parse.
Haaber det gav mening :>
Kiggede lige paa mit indlaeg igen og kan see at typeid ikke er i min thread tabel saa kan godt forstaa hvis der er lidt undren over det.
Igen vil det skabe ekstra redundans i commentdelen at have det ekstra punkt der - jf. mit db optimeringsargument :P
Efter at have tænkt det hele lidt igennem er jeg kommet frem til følgende
Tabel: forum_kategorier
katid, kategorinavn
Tabel: forum_forum
forumid, forumnavn, katid (så forummet kan høre til en kategori)
Tabel: forum_traade
postid, forumid (så tråden kan høre til et forum), traadid, userid, emne, indlaeg, status, sidsteindlaeg (så jeg kan sortere trådene efter nyeste svar), timestamp
Så det arbejder jeg efter lige nu.
Tabel: forum_kategorier
katid, kategorinavn
Tabel: forum_forum
forumid, forumnavn, katid (så forummet kan høre til en kategori)
Tabel: forum_traade
postid, forumid (så tråden kan høre til et forum), traadid, userid, emne, indlaeg, status, sidsteindlaeg (så jeg kan sortere trådene efter nyeste svar), timestamp
Så det arbejder jeg efter lige nu.
Nogen der kan forklare hvorfor følgende ikke giver unikke traadid, sorteret efter nyeste posts timestamp?
Sorterer den efter den har valgt unikke traadid?
Jeg har droppet feltet med sidsteindlaeg, da det jo burde kunne klares med timestamp - jeg skal bare have den nyeste fra hver unikke traadid.
SELECT distinct traadid FROM forum_traade WHERE forumid='$_GET[forum]' ORDER BY timestamp DESC
Sorterer den efter den har valgt unikke traadid?
Jeg har droppet feltet med sidsteindlaeg, da det jo burde kunne klares med timestamp - jeg skal bare have den nyeste fra hver unikke traadid.
#31
Ved ikke om du har skrevet det tidligere men bruger du MySQL eller MS SQL Server? ( og hvilken version? )
det vil hjælpe lidt hvis du skriver hvad den rent faktisk returnere...
Men prøv evt. at droppe "distinct" fra statementet eller at tilføje en "group by" der er nogle quirks omkring de to.. ( specielt i mysql )
Ved ikke om du har skrevet det tidligere men bruger du MySQL eller MS SQL Server? ( og hvilken version? )
det vil hjælpe lidt hvis du skriver hvad den rent faktisk returnere...
Men prøv evt. at droppe "distinct" fra statementet eller at tilføje en "group by" der er nogle quirks omkring de to.. ( specielt i mysql )
MySQL v4.0.15
Den returnerer traadid - bare ikke i den rigtige rækkefølge. Så vidt jeg kan se returnerer den altid den første unikke traadid-post den ser. Og i mit tilfælde er det selvfølgelig tråd-oplægget, som altså langt fra er det sidste svar.
Hvis det slet ikke giver mening..
Jeg har f.eks. 4 poster i tabellen forum_traade.
2 oplæg med hver ét svar. Hvert svar har altså hvert deres traadid, der svarer til oplæggets traadid. Alle poster har et timestamp.
Derfor vil jeg nu gerne have unikke traadid'er ud, sorteret efter hvilket har det nyeste timestamp. Hvis et svar også hører til det traadid skal det selvfølgelig også tjekkes.
Har forsøgt med group by, men det virker lige så lidt.
Den returnerer traadid - bare ikke i den rigtige rækkefølge. Så vidt jeg kan se returnerer den altid den første unikke traadid-post den ser. Og i mit tilfælde er det selvfølgelig tråd-oplægget, som altså langt fra er det sidste svar.
Hvis det slet ikke giver mening..
Jeg har f.eks. 4 poster i tabellen forum_traade.
2 oplæg med hver ét svar. Hvert svar har altså hvert deres traadid, der svarer til oplæggets traadid. Alle poster har et timestamp.
Derfor vil jeg nu gerne have unikke traadid'er ud, sorteret efter hvilket har det nyeste timestamp. Hvis et svar også hører til det traadid skal det selvfølgelig også tjekkes.
Har forsøgt med group by, men det virker lige så lidt.
Prøv denne her:
- SELECT statementet kan vist så hut jeg visker ikke sorterer på noget der ikke er selectet i MYSQL.
det er dog ikke det resultat du ønsker... understøtter MySQL sub queries i den version du har? ( gør den ikke i min gamle 3.23 )
SELECT distinct traadid,timestamp FROM forum_traade WHERE forumid='$_GET[forum]' ORDER BY timestamp DESC
- SELECT statementet kan vist så hut jeg visker ikke sorterer på noget der ikke er selectet i MYSQL.
det er dog ikke det resultat du ønsker... understøtter MySQL sub queries i den version du har? ( gør den ikke i min gamle 3.23 )
#37: Så vidt jeg kan se er de allerede escaped?
Karakterer som ' og " giver ikke SQL-fejl, men \' og \".
Hvis der er mere jeg skal gøre, så beskriv det lige.
#36: Sub-queries:
"As of version 4.1 of MySQL, however, sub-queries are now possible."
Så det kan den ikke.
Ellers må jeg vel finde unikke traadid'er i én sql sætning, og køre indlæg igennem where traadid='$var' i en anden.
Så er der bare lige det problem med at sortere dem i PHP..
Karakterer som ' og " giver ikke SQL-fejl, men \' og \".
Hvis der er mere jeg skal gøre, så beskriv det lige.
#36: Sub-queries:
"As of version 4.1 of MySQL, however, sub-queries are now possible."
Så det kan den ikke.
Ellers må jeg vel finde unikke traadid'er i én sql sætning, og køre indlæg igennem where traadid='$var' i en anden.
Så er der bare lige det problem med at sortere dem i PHP..
#38
så lige den her: http://www.mysqlfreaks.com/statements/18.php
det kan nok være til hjælp, læs også lige kommentarene da det ser ud til at det ikke virker i alle udgaver af MySql
så lige den her: http://www.mysqlfreaks.com/statements/18.php
det kan nok være til hjælp, læs også lige kommentarene da det ser ud til at det ikke virker i alle udgaver af MySql
#40
Enten:
eller hvis du får en sql fejl ( for gammel version til at den fatter at det kun er traadid der skal være distinct
Men hvis du siger du har prøvet...
Enten:
SELECT distinct (traadid),timestamp FROM forum_traade WHERE forumid='$_GET[forum]' ORDER BY timestamp DESC
eller hvis du får en sql fejl ( for gammel version til at den fatter at det kun er traadid der skal være distinct
SELECT distinct traadid,timestamp FROM forum_traade WHERE forumid='$_GET[forum]' ORDER BY timestamp DESC GROUP BY traadid
Men hvis du siger du har prøvet...
SELECT DISTINCT(traadid),postid,timestamp FROM forum_traade WHERE forumid='$_GET[forum]' GROUP BY traadid ORDER BY timestamp DESC
SELECT distinct traadid,postid,timestamp FROM forum_traade WHERE forumid='$_GET[forum]' GROUP BY traadid ORDER BY timestamp DESC
osv er prøvet, den sorterer stadig efter den finder distinct traadid'er. Jeg gætter på det ikke kan lade sig gøre i én SQL-sætning, da den (åbenbart) altid vil sortere resultaterne bagefter.
Derfor er det nødvendigt først at sortere, og derefter selecte distinct i hver deres sætning. Men jeg kan ikke lige regne ud hvordan den skulle klares.
Forresten så skal ORDER BY stå sidst, ellers brokker den sig.
SELECT distinct traadid,postid,timestamp FROM forum_traade WHERE forumid='$_GET[forum]' GROUP BY traadid ORDER BY timestamp DESC
osv er prøvet, den sorterer stadig efter den finder distinct traadid'er. Jeg gætter på det ikke kan lade sig gøre i én SQL-sætning, da den (åbenbart) altid vil sortere resultaterne bagefter.
Derfor er det nødvendigt først at sortere, og derefter selecte distinct i hver deres sætning. Men jeg kan ikke lige regne ud hvordan den skulle klares.
Forresten så skal ORDER BY stå sidst, ellers brokker den sig.
Kommer jo an på dine variabler og din kode hvad du får posted på siden. Med et select hiver du bare noget ud af databasen. Kan lige prøve at 'oversætte':
VÆLG * FRA forum_tråde HVOR forumid='$forumid' OG traadid='$tradid' SORTER EFTER tidsstempel FALDENDE
Derefter har du variabler for hver row i din tabel.
Eksempel:
Med den her kode, får du kun posted AREASUB fra tabellen STAFF og ikke resten af dataene. Det er klart at du godt kan indsætte ting som: if $traadid == $row["traadid"] etc.
For hver del i tabellen har du altså i dit $row array en variabel - $row["forumid"] osv.
VÆLG * FRA forum_tråde HVOR forumid='$forumid' OG traadid='$tradid' SORTER EFTER tidsstempel FALDENDE
Derefter har du variabler for hver row i din tabel.
Eksempel:
<?php
require('connect.php');
$asub2 = "0";
$result = mysql_query("SELECT * from staff ORDER BY areasub ASC");
while ($row = mysql_fetch_array($result)) {
if ($asub2 != $row["areasub"]) {
$asub2 = $row["areasub"];
echo "<option value='".$asub2."'> ".$asub2."</option>";
}
}
?>
Med den her kode, får du kun posted AREASUB fra tabellen STAFF og ikke resten af dataene. Det er klart at du godt kan indsætte ting som: if $traadid == $row["traadid"] etc.
For hver del i tabellen har du altså i dit $row array en variabel - $row["forumid"] osv.
Ja ok, jeg HAR prøvet at hive data ud af databaser før..
Jeg er godt klar over hvordan SELECT, UPDATE, INSERT, FROM, WHERE, ORDER BY, DESC, ASC, AND, OR osv virker :P
Jeg kan også sagtens finde ud af at putte dem i et array og echo dem i en while ud på siden (ellers ville jeg da aldrig have kunne lave resten af forummet, chipsguiden.dk og mange andre sider).
Problemet er sorteringen.
Jeg er godt klar over hvordan SELECT, UPDATE, INSERT, FROM, WHERE, ORDER BY, DESC, ASC, AND, OR osv virker :P
Jeg kan også sagtens finde ud af at putte dem i et array og echo dem i en while ud på siden (ellers ville jeg da aldrig have kunne lave resten af forummet, chipsguiden.dk og mange andre sider).
Problemet er sorteringen.
jaja :)
Men hvis den sætning i 45 ikke virker så er det muligvis et problem med databasen - for den virkede da i 3.x branchen.
Kan jo også være en ændring i SQL parseren i 4.x branchen.
Men hvis den sætning i 45 ikke virker så er det muligvis et problem med databasen - for den virkede da i 3.x branchen.
Kan jo også være en ændring i SQL parseren i 4.x branchen.
hov, kom til at tænke på at det måske er de data du smider i date-timestamp row. Du smider vel unixtid ind i den? For hvis du ikke gør er det garanteret derfor.
Jamen jeg har jo hele tiden brugt den "formel", SELECT blah FROM blah WHERE blah ORDER BY blah DESC, den har bare sorteret resultaterne efter timestamp - bagefter. Den har ikke sorteret posterne og derefter valgt distinct traadid'er ud.
Tror det er på tide med screenshots efterhånden ;)
Her er en oversigt over det vigtigste der er i forum_traade-tabellen lige nu
http://www.butiksguiden.net/forum/db1.png
Her er hvad SQL-sætninger med ORDER BY timestamp spytter ud:
http://www.butiksguiden.net/forum/db2.png
Som man kan se vælger den postid 1 og 6. Det er de første poster med NYE traadid'er (ikke de poster med nyeste timestamp).
Efter det sorter den så resultatet (postid 1 og 6) efter timestamp.
Tror det er på tide med screenshots efterhånden ;)
Her er en oversigt over det vigtigste der er i forum_traade-tabellen lige nu
http://www.butiksguiden.net/forum/db1.png
Her er hvad SQL-sætninger med ORDER BY timestamp spytter ud:
http://www.butiksguiden.net/forum/db2.png
Som man kan se vælger den postid 1 og 6. Det er de første poster med NYE traadid'er (ikke de poster med nyeste timestamp).
Efter det sorter den så resultatet (postid 1 og 6) efter timestamp.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund