T2 USER_ID2 -- Brev_ID, Brev_text, brev_dato 3 Hej1 1-2-3 _______________ med søgning - select * from T1
ialt : 100.000 tabeller, hver 100 rows (max)
SPØRGSMÅL : I øverste eksempel vil man ved 100.000user*100breve få max 10000000 rows der skal søges igennem. I nederste går du direkte ud i user (som er kendt) - og henter den info (max 100 rows) som vises.
Hvilken søgning er hurtigst - er det hurtigts at have alt i en DB med 1 tabel og mange rows eller mange tabeller og få rows der søges igennem. Det skal dog siges, at eksempel 2 er lagt i sin egen selvstændige database - og der skal derfor tages højde for der, at der også skal åbnes op for ny database ved dette kald.
Det vil altid koste mere tid, når man i et SQL-statement har joins, altså relationer mellem flere tabeller. At søge en enkelt tabel igennem vil altid være langt det hurtigste. Dermed ikke sagt at det er den rigtige løsning. I dit tilfælde er det mest korrekt med to tabeller, ellers får du et problem med at brugernes data er repræsenteret flere gange (er et problem ved opdatering).
Hvis man altid puttede alt i én tabel ville det jo bliver noget juks, som ikke er til at finde rundt i :)
Med al respekt tror jeg ikke at du har læst spørgsmålet grundigt nok. Der er ingen joins i nogle at tilfældene. Det er 1 tabel og en WHERE betingelse versus 100000 tabeller og ingen WHERE betingelse. Og der vil ikke være redundate data bare et mareridt af ens tabeller.
Arne_v har ret - Med den query du viser, vil du uden index få et full-table scan som du selv er inde på. Men med et index på user-id bliver svarmængden langt mindre. Så at hente 100 fra 100,000 er ikke noget problem, med mindre du begynder at lave underlige queries hvor databasen ikke har mulighed for at bruge indexer. MEN: Du skal huske at opdatere 'statistics' på din database/tabel med de størrelser data, ved ikke om MySQL har noget automatisk til det.
Arne v : yep er klar over, at eks. 1 er den traditionelle måde at opbygge en db på. Mht. indexering - så er jeg lidt i tvivl - for hvordan skal jeg lave index på eks. brev_id (i eks. har jeg godt nok sat dem som brev 1,2,3) men virkligheden ser anderledes ud - der er brev_ID autogenereret ud fra en dato. Mht. userid så vil user_id jo forefindes op til 100 gange i eks. 1. (da der er 100 breve fra hver user). Mht. vedligeholdelse yep kan godt se det måske er nemmere - dog kan man jo sige at ved eksempel 2 - har du en seperat DB som du kan smide et andet sted hen og kører eksempelvis i et større system fra en anden server.
dsj : Du har nu ikke helt uret alliegevel - for Ja der findes naturlivis en tabel med userinfo - og det ville betyde en Join hvis userinfo skal udtrækkes sammen med brevinfo. dvs så har jeg 2 DBaser, som der leges med på en gang. DOG er samme data jo så heller ikke repræsenteret det samme sted (så normalisering er iorden).
zapzap : som dig og arne er inde på mht. indexes - så måske jeg bare skal læse lidt mere om dette. Dog stadig mener jeg ikke indexering er helt på sin plads (jo mht. størrelse), da brev_id ikke er kendt kun userid som er repræsenteret 100 gange i samme tabel pr. user. og Nej det er jo ikke 100 ud af (100.000) breve men 100 ud af (100.000 * 100 breve), der vil ligge som rows contra 100.000 tabeller med hver 100 rows. Og som sagt er det jo user_id, som er den kendte parameter og ville derfor kunne lægges ud som en tabel i sig selv indeholdende users brevinfo. - her skulle alt så bare udtrækkes.
konklusion : eks.1 - 1db åbnes 100.000*100 rows gennemsøges (med/uden indexering - brev_id ukendt, user_id kendt men 100 af dem)
eks.2 - 2db åbnes 100.000 tabeller forefindes - tabel er kendt og data udtrækkes.
så jeg forstår det som : kun hvis indexering forefindes vil eks. 1 være hurtigst !
Tak for svar - og vil da naturlivis gerne lige have en opfølgning på denne kommentar :).
ok tak arne :) - jeg vil dybdelæse lidt om de indexes :) er helt klar over, at hvis jeg KAN indexerer denne ene tabel med de mange rows - så er det at foretrække. var ikke helt klar over, om man kunne indexerer noget, som ikke var unikt.
arne v. Så har jeg læst lidt på de forskellige indexeringer. Kan godt se, at indexering er klar at foretrække frem for oprettelse af nye tabeller for hver user. - også fordi en tabel jo fylder - og tør ikke tænke på hvis der var 100.000 tabeller i en db :) - bare tanken om windows, som skal åbne et dir med 100.000 filer heheheh, så kan jeg godt se hvilken tid det også kunne tage at åbne en DB med 100.000 tabeller. Eneste minus er jo så bare (kan man sige) at netop en brev database skal der tit skrives ned i (og ikke kun bruges som søgning) - og mht. indexering så er det jo tidskrævende mht. skrivning, updates og sletning da index skal vedligeholdes. men alt ialt så er index løsningen på EN tabel med mange rows at foretrække frem for mange tabeller og få rows (også fordi denne sidste løsning er stik imod god db opbygning).
Synes godt om
Ny brugerNybegynder
Din løsning...
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.
