26. april 2007 - 17:40Der er
6 kommentarer og 1 løsning
Bedst struktur for håndtering af data i DB
Jeg har en net applikation i ASP.NET som skal håndtere data for klubber. Måske 100 klubber - 50 mand hver eller måske op til 1000 klubber - 50 mand hver.
Hvad er den bedste metode til at strukturere data for disse ? Jeg har en applikation, som de alle skal kunne køre , men uafhængigt af hinanden.
1. Jeg laver en hel ny Db til hver
2. I een DB, laver jeg nye tabeller svarende til hver klub, således Club1_Table1, Club1_Tabel2 op til ClubN_Tabel1 og ClubN_Tabel2 (hvis nu min app kører på data fra kun to tabeller - i realiteten drejer det sig om 6 ). Jeg ender op med mange tabeller, men ingen overhead på SQL, da jeg leder i ret tabel fra starten.
3. Jeg laver een DB, men hver linje får en ClubID tilføjet, så alle mine SQL-sætninger, et eller andet sted i et mellemliggende lag, får tilføjet den passende ClubID,svarende til den club hvis medlem er på, og søger i DB'en.
4. Andre metoder ?
Ingen roser uden torne - hver metode har vel sine forttrin og ulemper, men jeg har svært ved at vurdere disse. Læg venligst et bidrag :-)
(Mit tilsvarende spørgsmål før hen var vist formuleret for bredt, så det er lukket (så snart snepnet kommer forbi)
Tak for oplysningerne hidtil. Den aktuelle applikation er en aktiviteskalender - og nu er klubberne ret aktive så med 1 aktivitet/dag/medlem så har jeg 50,000 aktiviteter per dag som jeg skal kunne håndtere.
Jeg jonglerer lidt med diverse sql-joins osv, og muligvis kan jeg slippe for en ClubID i hver aktivitets-post men det er ikkke sikkert. Det er mange data at lede igennem for kollisioner/ferier osv osv. Er nr 3 stadig bedst så ? Løsning 2 er en jeg så i nogle af de gratis portaler man kan DL'e - det var vist ASPNUKE eller NUKE eller DOTNETNUKE. Systemet havde indbygget mekanik til at lave nye tabeller for hver ny forening som skulle oprette, så det er ikke en uoverkommelig opgave at lave noget tilsvarende selv. Jeg kan ikke vurdere om en SQL DB performer bedre med mange data i få tabeller (og med en ekstra key) eller mange små tabeller. Nogen mening om dette ? Er der andre hensyn at tage (end søgeperformance)?
Det skal være noget som er skalerbart (selv om, hvis jeg skal skalere mig ud af en normal server, så er systemet vild success, og er for længet blevet opkøbt af Google, som vist ikke har skaleringsproblemer:-)
Jeg lukker dette spørgsmål fordi de svar som er kommet er for mig ikke tilstrækkelige til at træffe en beslutning. Jeg ser gang på gang at option 2 bliver implementeret af de professionelle, og der er sikkert en god grund til det: formentligt for at slippe at searche igennem kæmpe tabeller. Jeg er ikke sikker, derfor spurgte jeg.
Medmindre der er specielle forhold (behov for at implementere streng adgangs kontrol på database niveau fordi databasen skal tilgåes direkte af 3. parts værktøj eller andre rariteter), så er løsning #3 den rigtige.
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.
