04. december 2003 - 11:33Der er
5 kommentarer og 1 løsning
Flere databaser med sammenkædede tabeller
Jeg overvejer, hvad der er det mest hensigtsmæssige design og opsætning af mine fire databaser, og om jeg burde lave et nyt design.
Selvom beskrivelsen måske er lidt rodet, vil jeg prøve at skitsere situationen: For øjeblikket arbejder jeg med fire forskellige databaser, hvor alle er opbygget med de samme formularer, forespørgelser, rapporter, etc. Hver base har tabeller med ens navne (Persondata, Konkurrencer, Resultater, Discipliner) men med unikt indhold. Tabellerne har jeg givet ens navne for at de virker med forespørgelserne, rapporterne, etc. I den ene af databaserne har jeg yderligere tre tabeller, som alle fire baser trækker data fra.
Jeg overvejer et nyt design, da jeg gerne vil have et system, der letter mit arbejde med at: - tage backup af tabellerne fra alle fire baser. - redigere formularer, rapporter, etc. - Eksportere, opdatere formularer, etc. til de andre baser.
Jeg har blandt andet overvejet, at samle alle data i en base, men det vil skabe problemer i forhold til tabellerne i hver base har unikt indhold. Samtidig vil det betyde, at selve basen og opdateringsmakroerne vil køre meget langsommere end de allerede gør. Computeren jeg sidder med, er nemlig ikke den hurtigste. :-(
Hvis du har fire saet tabeller som hver indeholder unikke data men med fuldstaendigt samme struktur vil det vaere langt nemmere at laegge alle disse dat sammen i stoerre tabeller. Nu ved jeg selvf ikke hvor meget data det drejer sig om men det lyder helt sikkert som om det vil vaere meget, meget nemmere at styre det hele fra en enkelt db. Hvis det skal distribueres til flere brugere paa et tidspunkt kan du overveje at lave fronted/backend hvor alle formularer og queries ligger i frontenden med links til din backend hvor al raadata findes i tabellerne.
Jeg har overvejet det, men jeg er bange for at datamængden bliver for stor = nedsat søgetid.
Indholdet af de tre mest centrale tabeller beløber sig til: A: ca. 350 poster B: ca. 360 poster (jævnt stigende) C: ca. 11500 poster (jævnt stigende)
Jeg har også være inde på at arbejde med frontend/ backend, da jeg gerne vil tage backup af data på min stationære computer. Spørgsmålet bliver her, hvordan opdaterer og justerer jeg i formularer, etc.?
OK jeg ville ikke mene at omkring 12-15.000 poster skulle vaere det helt store problem, men det kommer selvfoelegewligt an paa din computer. Men siden du allerede har 11500 i en database mener jeg at tilfoejelsen af de oevrige ~700 vil have forsvindende lidt effekt
Mht backend/frontend. Grunden til at dele det op i backend og frontend er normalt primaert for at kunne enten dele data med andre over et netvaerk. Fordi det kun er tallene der skal sendes over netvaerket oeger det ydelesen af databasen vaesentligt fremfor at man bare aabner en central database f.eks. I dit tilfaelde lyder det egentligt til at du kun arbejder paa den selv, hvorfor der nok ikke er den store grund til at begynde at dele den op - istedet ville jeg bare lave en backup paa din stationaere pc med jaevne mellemrum istedet.
overchord > jeg må vist lige komme med en nærmere præcisering af mine bogstavkoder. A, B og C henviste til de tre hovedtabeller i hver base. Dermed vil en samlet tabel C nå op på over 45000 poster.
Ville det så være en god ide at at samle de 16 (4x 4) i en database og bruge den som udgangspunkt for FE/ BE, hvor jeg kun linker til de tabeller jeg har brug for?
Har valgt at samle de fire databaser i en backend, men med unikke tabelnavne. I FE ændrer jeg linknavnet til standardnavnene, og så stemmer pengene.
Lukker her...
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.
