# Henter feltet 'post' $hent_laeste = mysql_result("SELECT post FROM tabel1 WHERE user = '1'")or die(mysql_error()); // Bruger bruger-id'et 1
# Nu skal du splitte feltet 'post' op i en array. F.eks: $laeste = split(",", $hent_laeste); // Splitter ved komma
# Henter antal indlæg som ikke var at finde i feltet 'post' $hent = mysql_query("SELECT count(*) FROM tabel2 WHERE id NOT IN ('".implode("','", $laeste)."')")or die(mysql_error());
# Udskriver antal ulæste indlæg echo mysql_result($hent, 0, 0);
cronick: Hvorfor er det lige at du vælger at splitte feltet på ?? Du gemmer vel ALDRIG flere værdier i samme felt. Desuden så bruger du mysql_result forkert og eftersom du samler det data du lige har splittet op, giver det bestemt ikke mening at lave den ekstra kode.
Måske sådan her: ;-) mysql_result("SELECT post FROM tabel1 WHERE user = '1'")or die(mysql_error()); // Bruger bruger-id'et 1
Men jeg tror netop ikke der gemmes flere værdier i et felt. Den ene tabel ligner en M-M relationstabel, hvor bruger-id godt kan stå flere gange i tabellen.
"Jeg har en tabel som ser således ud: user (int), post (int) som indeholder bruger-id og post-id med alle de post-id en bruger HAR læst."
dkfire, jeg synes ærlig talt det bør være en anelse pinligt for dig, når jeg fortæller dig, at min mysql_result() er korrekt, mens din er helt hen i vejret. Forhåbelig vil du undersøge tingene nærmere i fremtiden, før du begiver dig ud i at kritisere andres metoder.
Mht. selve problemet så synes det, at vi har to forskellige indblik i hvordan han har opbygget sit system. Det kan meget vel være aktuelt, at jeg har taget fejl mht. beskrivningen af hans tabel - jeg har dog tydet den efter hvordan jeg lige fangede hans beskrivelse, og hvad der ville være naturligt hertil.
eikhorsholm, lægger du alle post-id ind i samme række i 'tabel1', for hver bruger? Det ville betyde, at hver gang en bruger læser et indlæg, indsætter du en ny række i 'tabel1', hvis brugeren ikke allerede har en. Hvis brugeren i stedet allerede har læst et indlæg, og derved har en række i 'tabel1', opdatere man blot den række, ved at tilføje et ekstra id i en given celle (f.eks. en celle kaldet 'post-id' med indholdet: 13,29,2,19). Dvs. du derved slipper for at have uoverskueligt mange rækker, selvom du har mange indlæg. Hvis du dog ikke benytter denne metode, så må du selvfølgelig lige sige det :-)
cronick: Jeg kritisere dig slet ikke, men hvis du ser hvad jeg skrev, så har jeg bare taget et udpluk fra din kommentar 04/09-2008 12:55:14. Du skriver: # Henter feltet 'post' $hent_laeste = mysql_result("SELECT post FROM tabel1 WHERE user = '1'")or die(mysql_error()); // Bruger bruger-id'et 1
# Nu skal du splitte feltet 'post' op i en array. F.eks: $laeste = split(",", $hent_laeste); // Splitter ved komma
hvilke jo nok bør være:
$hent_laeste = mysql_query("SELECT post FROM tabel1 WHERE user = '1'")or die(mysql_error()); // Bruger bruger-id'et 1
# Nu skal du splitte feltet 'post' op i en array. F.eks: $laeste = split(",", mysql_result($hent_laeste,0)); // Splitter ved komma
Og så har jeg heller aldrig skrevet at du misbrugte mysql_result, bare at du brugte den forkert, som beskrevet øverst.
Ang. hvordan værdier lægges i tabeller og felter, så er det bestemt aldrig en god ide, og har aldrig været ideen med database, at lægge flere værdier i samme felt. Det kan godt være du synes det er nemmere at overskue når du ser tabellen i PHPMyAdmin, men det en rigtig dårlig måde at opbygge sin tabel på den måde. Når du kun har en værdi i dit felt har du langt flere muligheder for at bruge ren sql til søgninger og relationer, end hvis du har flere værdier i samme felt. En "Mange til Mange" relation løses ikke ved at have et felt med mange værdier, men at have en tabel imellem de to tabeller som skal relatere, og lade den tabel styre "Mange til Mange" relationen. Du vil nemt kunne tilføje, slette og søge i relationer mellem de to tabeller, uden at skulle ind i et felt og behandle værdierne.
"Ang. hvordan værdier lægges i tabeller og felter, så er det bestemt aldrig en god ide, og har aldrig været ideen med database, at lægge flere værdier i samme felt."
Det er da muligt, at de ikke har taget højde for dette, da MySQL blev lavet. Det ændrer dog ikke på det faktum, at det i flere tilfælde er den mest optimale fremgangsmåde. Hvis man f.eks. har 5000 bruger i sit forum, og der i dette forum er skrevet mere end 1000 indlæg. Med lidt hurtigt matematik når man hurtigt frem til, at der i alt er mulighed for 5.000.000 rækker i ens tabel, hvis alle brugere læser alle indlæg. Hvis man derimod bruger min metode, og smider alle de læste indlæg's id'er ind i en selvstændig række til alle brugere, vil man slippe med maksimalt 5.000 rækker, uanset hvor mange indlæg de forskellige brugere læser. Det giver ærlig talt en betydelig forskel, når man skal foretage Query's, som ikke blot henter data fra én tabel, men eventuelt krydschecke to tabeller, for at hive relevante sammensluttede rækker ud fra en anden tabel. At MySQL ikke har været så smarte, at lave en split-funktion til brug på en celle, er selvfølgelig beklageligt. Derved er det rettere umuligt at gøre det hele i én Query, i denne situation. Men det ændrer ikke ved, at det optimeringsmæssigt kan betale sig.
"Og så har jeg heller aldrig skrevet at du misbrugte mysql_result, bare at du brugte den forkert, som beskrevet øverst."
Det er korrekt. Men 'at misbruge' noget kommer formelt af at bruge noget misvisende, og det er jo reelt hvad du mener om mit brug af mysql_result(). Jeg venter forresten stadig på din uddybning af hvordan dit brug af mysql_result() er korrekt, mens min er forkert. For mig at se, forholder det sig lige omvendt, da du behandler mysql_result() uden nogen ekstra parametrer, samt glemmer at bruge mysql_query() rundt om din SQL-sætning.
Hmmm nu har jeg to gange vist din kode og hvor jeg mener du har brugt mysql_result forkert. (Tror DU manglede en mysql_query) Men hvis du mener at den kode jeg er kommet med indeholder fejl, må du da meget gerne vise hvor. Husk dog lige at de to kodeeksempler jeg gav i 05/09-2008 12:35:34 indeholder din gamle kode og en ny, og rettet, kode fra min side.
Dog synes jeg stadig du gerne må forklare hvorfor DU mener at følgende kode er så korrekt (Dette er DIN kode): $hent_laeste = mysql_result("SELECT post FROM tabel1 WHERE user = '1'")or die(mysql_error()); // Bruger bruger-id'et 1
Så vidt jeg kan se så mangler der en mysql_query, hvilket jeg også, indtil flere gange, har gjort opmærksom på. Mysql_result tager ikke en sql som parameter, men en mysql_query link. Dette viser du faktisk også senere i det samme kodeeksempel, og min første kommentar var bare at gøre dig opmærksom på at du måske havde skrevet til forskert i de første par linjer ;-).
Men for mig at se, så har du svært ved at folk kommentere og retter i din kode, samt anviser en smartere måde at gøre tingene på.
Ang. mysql og antallet af rækker. Så er 5 mill. rækker intet for en database og de få millisekunder som du kan opleve at det taget af ekstra tid, er intet i forhold til det bøv du får ved at have flere værdier i samme felt. Om en tabel indeholder 5 rækker eller 500 millioner rækker er sådan set ligemeget for mysql, den skal nok finde dem, og om du så henter flere rækker ud på samme tid er også ligemeget for mysql, den skal nok gøre det. Du kan dog ikke i dit tilfælde hente fra mere end en tabel, burgere i dette tilfælde, da du kun har mulighed for 1 reference. Og hvis du har 5000 brugere på din side, så bliver det godt nok til mange ekstra mysql kald for en operation som kunne laves smartere. Og det er ikke kun mysql som er indrettet på den måde, sådan gælder det for de fleste store databaser. Jeg kender pt ingen som med lidt fornuft og kendskab til databaser, vil vælge at opbygge sine tabeller så der i et felt findes flere værdier. Du mister hele ideen med en relationsdatabase på den måde. Tænk hvis du nu gerne vil finde ud af hvor mange brugere som har læst artikel 6.
Det er først lige gået op for mig, at du rent faktisk refererede min første Query, og ikke blot foreslog en korrekt. Jeg havde slet ikke bemærket, at jeg brugte mysql_result() mere end ét sted (dvs. udover den i slutningen), så fejlen påtager jeg mig selvfølgelig gerne, og beklager meget forvirringen :-)
Mht. de to forskellige metoder, så kan jeg godt se, at min kræver nogle seriøse processer, for bl.a. at skulle krydschecke hvor mange bruger, der har læst et specifikt indlæg. Min erfaring er bare, at når det kommer til brug af forskellige JOIN's, med mange rækker i en tabel, så bruger MySQL enormt meget kraft og tid på at returnere det ønskede svar.
Jeg kunne heller ikke helt forstå at du blev ved med at påstå at det var min kode som var fejl i, men helt okay, nu er vi da enig ;-)
Nag. join, så kommer det meget an på hvordan du joiner de forskellige tabeller. Jo hurtigere du kan mindske antallet af rækker, med et eller flere udtryk, jo nemmere og hurtigere at mysql ved at behandle de resterende rækker. Hvis du har problemer med en join, så prøv at lave en show/explain på din sql sætning og se hvor lang tid det tager. Dernæst kan du prøve at ændre rækkefølgen på dine udtryk og se om det ændre på tiden. Noget med at "WHERE felt1 = 'etellerandet' and felt2 = 'etellerandet'" ikke er det samme som "WHERE felt2 = 'etellerandet' and felt1 = 'etellerandet'. Evt. kan rækkefølgen af tabellerne som du joiner også have betydning. Håber det gav bare lidt mening ;-)
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.