Jeg har en users-tabel på ca. 11 mio rows. Den er tilknyttet et website som opererer i 7 lande.
Sitet fungerer som sådan super duper rigtig fint med én stor users tabel, men af nogle interne årsager har jeg også brug for lande-specifikke tabeller.
Jeg har brug for en udgave af denne users-tabel som er spejlet/synkroniseret ud i en række landespecifikke tabeller, fx:
"users_dk" "users_fr" "users_fi" "users_se"
...osv...
Vi kører MS SQL 2008 (64bit) og jeg kan leve med, at dataerne er op til 10 min forsinkede.
Det er _ikke_ en option at hardcode noget ind i site-koden da den er virkelig omfattende. Jeg har derfor brug for noget der kører automatisk på serveren og som kan klare jobbet for mig.
Jeg går ud fra at når du skriver spejlet/synkroniseret, er dette til tabeller på den samme server, måske endda i den samme database?
Det du så har brug for, er at der bliver lavet en SSID, som sættes til at køre med evt. 10 min. mellemrum, som kopierer dine users ud i andre tabeller baseret på deres land.
En SSID?? Kan replikering ske internt i databasen? Det er mere spejlede databaser, så det dur nok ikke. Replikering er også noget hø at vedligeholde.
Det letteste er nok et job der med faste mellemrum fyrer en StoredProc af. Bedst kombineret med et flag i brugertabellen om den er opdateret eller ej. Det kunne du styre med en trigger på OnCreate og OnUpdate via de interne "Inserted" og Updated" ... og "Deleted" tabeller, hvis du sletter.
HRC: Nu har du en masse spørgsmålstegn i dine to første sætninger, så ved ikke hvad der er stilet til hvem.
Det er osse noget 'hø' at smide nyt tag på mit hus, men det er jo kun for mig, for andre er det jo nemt. Såååå
I SQL 2000 og derfør var der Data Transformation Services (DTS) og schedulering via SQL Server Agenten
Efter SQL 2000, bevægede vi os over på SQL Server Integration Services (SSIS), et værktøj der er stærk undervurderet (specielt i Danmark) til til databehandling, være det sig simpel kopiering af data, eller import/export af data fra/til externe leverandører osv.
Anyway, der er mange måder at lave ting på, mange tager lige lang tid og er lige effektive, og nogen er det modsatte.
steent: Nu var der altså kun 2 spørgsmålstegn. Jeg har desværre kun set SSIS demonstreret en enkelt gang og det så da flot ud.
Den primitive med en triggerløsning der kopierer ved insert eller update kunne gøre det, men den er sikkert ikke hurtig, idet triggers jo altid sidestilles med langsom (sikkert uforskyldt).
Replikering er altså noget hø (godt jeg ikke skrev lort, for det var noget værre noget på dit tag). Justering af tabeller og den slags er direkte træls - hvis man ellers når dertil inden ens pool af login og passwords løber tør.
HRC: "Jeg har desværre kun set SSIS demonstreret en enkelt gang og det så da flot ud."
Som jeg sagde, desværre er DTS og den efterfølger SSIS ekstremt undervurderet i specielt Danmark, hvilket er en skam, da det er et kraftfuldt værktøj.
Men jo, 'replikering' ville nok heller ikke være den løsning jeg ville vælge til opgavestilleren, det optimale ville jo være en gang for alle, at få delt brugerne op i forskellige landespecifikke tabeller.
Flere ting her... SSIS er absolut mindst anbefalelsesværdigt til den opgave. SSIS er kun til integration imellem forskellige kilder.
Replikering er ikke noget hø at vedligeholde, men derimod ikke velegnet hvis tabellerne ligger i samme database på samme server.
At kode sig ud af det med nogle tilstande som skal vedligeholdes er noget man slet ikke skal give sig i kast med. Det vil 100% give dig problemer på et tidspunkt.
Hvis det blot er pga. performance og det hele alligevel skal køre fra samme server så vil det ikke gå hurtigere at have flere tabeller, her vil man derimod benytte et index, nonclustered, partitioned måske.
Jeg kan måske til nød forstå behovet for flere tabeller hvis vi snakker over 1.000.000.000 rækker, men så igen.... alt afhængig af index... min pointe er bare at det skal handle om andet end performance førend man deler det ud i tabeller.
Nå... Melder mig ud, kan i have en god diskussion. Den ene er mere int. end den anden i at fortælle hvor dårlige de foskellige løsningsforslag er. Det er jeg enten for dum til at forstå hvorfor man gør det, eller jeg bevæger mig ikke på et sådant niveau..
Og det gør du alligevel ved at komme med den kommentar.
Vi (jeg gør i hvert fald) snakker for det meste altid om den bedste løsning, og det tror jeg også sprørger er interesseret i. At du så kalder det at bevæge sig "på et sådant niveau" må være for din egen regning. Kan godt det sted du arbejder ikke går ind for snakke ting igennem for at vælge den bedste løsning på et givent problem, men det er der heldigvis andre der gør. Derfor der er kommet de ting på bordet.
At løsninger så måske bliver kaldt for dårlige, så vend den lidt om ... og du kan jo så kalde dem mindre gode, i stedet for at blive "pige sur" :-).
janus: Jeg er nok bare en klovn for jeg har bøvlet med replikering i flere måneder på at lave en simpel snapshot replikering, der er stabil nok til jeg kan overlade den til kunder. Det på en måde hvor der er styr på opsætning og procedurer i forbindelse med opdateringer og ændringer. Det er noget bøvl! Kunne have kodet det på samme tid.
Hej hrc Ja jo... altså kan sagtens følge dig og har selv siddet flere gange med replikeringsproblemer, men altså... jeg har alligevel valgt at være fortaler for det, det giver en masse sikkerhed, overvågning osv. "out of the box"
At kode selv er jo altid et alternativ der skal overvejes, men mange ting kan gå galt... publisher eller subscriber kan gå ned, flere subscribere (en kommer online, en anden ikke osv), referentiel integritet og synkronisering, conflicts? subscriber updated/ publisher updated, merge osv.
janus: Replikering virker og jeg kender ikke bedre måde at kopiere en central database ud på en bærbar. Jeg startede på bar bund og kom ind i replikering på en dårlig måde. Nu er jeg mere fortrolig med det hele er og erkender så, at man ikke sætter uuddannede kunder til at administrere det - og det var hensigten da jeg promoverede løsningen. Derfor forsøger jeg at kode alle trin så kunderne har et skræddersyet program at administrere i. Det spiller ... næsten. Problemet er at jeg flere gange har kæmpet meget længe for at slippe af med "næsten". Jeg har endda måtte kalde på ekstern hjælp. De tager herfra efterladende mig miracleløst en del klogere, hvorefter jeg flyttes til et andet projekt og først vender tilbage når alt er glemt igen! Derfor måske lidt uforskyldt, men JEG ER TRÆT AF REPLIKERING (for jeg får aldrig opgaven gjort færdig)!!
.. desuden er en publiceret database ret besværlig at justere. Væk med artiklen, ret, på med artiklen igen, lav ny distribution.
Nok brok, og det i en anden mands spørgsmål. Jeg klebager, men det måtte ud!
Jeg kan godt følge dig... men jeg har nok bare lige fået overkommet det der "næsten" med tiden :)
forresten så understøtter SQL2008 at man løbende kan ændrer på schemaet, både fjern og tilføj kolonner :) Indrømmet... det var ret besværligt tidligere.
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.
