20. maj 2003 - 18:32Der er
7 kommentarer og 2 løsninger
Optimal DB (Flere tabeller eller en)
Hej.
Jeg har netop haft en diskusion med et par gutter, om det bedst kan betale sig at have EN DB eller flere.
Jeg har 10 nøjagtigt ens tabeller, der hver repræsentere data skrevet på forskellige sprog. Da jeg har brug for at kunne inddele mit website efter data skrevet under forskellige sprog, har jeg flg. to muligheder:
- Have en DB til hvert sprog (nuværende løsning) - Have EN DB til det hele, og fx. have et felt med navnet (sprog) som jeg så sortere efter vha. "WHERE sprog.." osv.
Ifl. Tipsen her på eksperten, vil sidstnævnte løsning være den hurtigste. Men det kan jeg simpelthen ikke forstå. I den første løsning henter den jo blot alt i den pågældende tabel. Hvis jeg benytter den anden løsning, så skal der vel foretages en "søgning" af en art i selve tabelle, for KUN at udskrive de aktuelle celler, som er markeret med et specielt sprog.
Hvad er den bedste løsning helt nøjagtigt ?
- Jeg fik også at vide, at hvis man har flere tabeller der rent struktuelt ligner hinanden, så er den bedste løsning at slå dem sammen. (Lyder jo faktisk meget klogt, at indordne sine tabeller efter, hvordan strukturen er)
Jeg fåstår ikke hvorfor du har valgt at indele det i flere databaser i stedet for at bare have de 10 tabeller i den samme database, så du kun ville skulle have en connection til din database. Det vil i hvert fald ikke gøre det hurtigere at have delt det ud i flere databaser. Hvis du vil have det hele ind i samme tabel skal du huske at lave en ekstra tabel som du har dine sprog i så du kan joine de to tabeller da det er en del hurtigere at joine tabeller på et id end at bruge en f.eks. where sprog = dansk, desuden vil det også fylde mere hvis du f.eks har det samme sprog stående mange gange i din tabel. Men det vil nok være hurtigst at have det delt dine tabeller ud på sprog da du så slipper for at tjekke på sprog
Det kan absolut ikke betale sig at have flere databaser. Det kræver en connection på hver og normalt kan man ikke forespørge på tværs af databaser.
Det er næppe performance der er afgørende for om du vil have flere tabeller eller kun en. Det er primært et spørgsmål om hvad der er nemmest for applikationen der skal bruge den/dem.
I dit tilfælde synes jeg absolut at det lyder som det vil være nemmest at samle data i en tabel.
Det er nemmere at tilføje et nyt sprog.
Formentlig kan du også nøjes med mindre applikations kode til normal vedligehold.
Men I mener altså, at den bedste metode er at have alle poster i EN tabel, og så have en kolonne der fx. hedder sprog ?
Så kan jeg jo netop lave en "Where sprog = $lang" i min Select-streng. Men det er denne form for "søgning" jeg er bange for vil blive RIGTIG tung, når der nu engang kommer flere tusinde poster.
Så ville jeg umiddelbart tro, at det ville være hurtigere at benytte flere tabeller, så en "where"-parameter ikke var nødvendig.
det vil helt sikkert være hurtigere men det er nok ikke noget du vil kunne ligge mærke til, for der skal alligevel være en del poster i en tabel før det begynder at blive tungt. Det er nok mere en smags sag med hvad man finder nemmest at gøre
well, jeg er interesseret i den mest optimale løsning (selvfølgelig) - så hvis flere tabeller er den bedste løsning, mht. hastighed og flexibilitet, så er det den løsning jeg vælger.
Det kræver næsten ingen CPU, så det er et spørgsmål om hvormeget data der skal læses fra disk.
Hvis de mange små tabeller er kontinuerte på disk og hvis den store tabel ikke er naturligt grupperet efter sprog, så kan det godt være at der skal læses mindre.
Men det er altså nogen hvis'er og nogle formodninger om hvordan databasen virker.
Lav et pænt database design og hvis performance er et problem, så prøver du forskellige ting for at gøre det hurtigere.
Det er ikke smart at lave sit design for at tage højde for et muligt performance problem udfra ens formodning om hvordan databasen internt fungerer.
Flere tabeller har helt konkrete ulemper: - du skal rette i database struktur (oprette en ny tabel) for at tilføje et nyt sprog - du kan meget nemt komme til at replikere applikations kode for at gøre det samme ved forskellige tabeller - visse former for queries bliver mere komplekse (bl.a. statistik queries vil nemt blive en kæmpe union)
Arne_V > Ok, det ser ud til, at du har styr på sagerne. Jeg må også indrømme, at der er EN stor fordel ved at have EN tabel. Jeg vil nemlig gerne kunne udskrive, hvor mange poster en given person har oprettet - og det ville være svært, hvis der var 10 tabeller der skulle gennemsøges for et brugernavn, hvorefter tallene skulle lægges sammen.
Så jeg tror jeg følger jeres gode råd, og samler det hele i Én tabel. Så må vi sortere vha. en sprog-kode som fx. Dansk=da, tysk=de, eng=us etc.
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.
