Db-design til opsamling af statistik

Hvad har du til rådighed? Multidimensionelle strukturer? eller kun en relationel database?

Du skal også lige tænke over at som en tommelfingerregel så er databaser der er hurtige at indætte i langsomme at læse fra og omvendt. (tror engang jeg skrev en artikel omkring datawarehousing her på sitet :-) )

På SQL Server 2005 har du Analysis Services som er bygget til at lave store, komplekse udtræk fra i det den pre-aggregerer kombinationerne (min artikel) Problemet her er at sådan en skiderik skal "processeres" hvilket kan tage nogle minutter alt efter hvor meget data du har, det data du vil se er altid "gammelt" (fra sidste gang du processerede) - men det kommer du ikke udenom.

Et andet problem du vil løbe ind i er at du skal tage stilling til om din statistik skal ske real-time eller "kun" nær real time. Problemet er typisk at du vil stille en række forespørgsler som giver dig data og så stille en forespørgsel der summerer dine data (dette er typisk 2 forskellige forespørgsler). Hvis du kører sand real-rime har du risiko for at der er indsat eller slettet i din database mellem du selecter rækker og selecter sum, det betyder at din sum ikke matcher dine rækker - dine data er nu korrupte!

For at løse dette problem laver man typisk to databaser en stage og en analysedatabase (min artikel) og så engang imellem når man ved at sin kildedatabase er i en konsistent tilstand, så overfører man alle data til sin stage (eller sin analysedatabase alt efter hvor avanceret man er)hvor man så kan lave konsistens kontrol (referentiel integritet). Så har man som udgangspunkt et konsistent datagrundlag at analysere på.

P.S. 3. normalform vil være tilstrækkelig, og give tilstrækkelig hastighed ved udlæsning (den tager lidt længere tid at indsætte i)

Det lyder til at være en hård nød at knække. Vi er selv lige begyndt på normalisering i database på studiet og spørgsmålet er om du overhovedet kan undgå redudans i data, så jeg vil mene at kan du opnå en 1NF (1. Normal form), så kan det nok ikke gøres mere på den front. Hvad har du selv overvejet? (Bare for at have noget at tænke videre på).

Jeg synes du skal have en tabel til alder, og en tabel hvor du "samler" det andet. Nu ved jeg ikke hvor meget mere der samles, men jeg kan lige smide et udkast til hvordan jeg nok vil samle det.

Tabellen kan måske se ud noget hen ad i den stil.

 CREATE TABLE agegroup (
     age_id smallint NOT NULL,
     age smallint NOT NULL,
     PRIMARY KEY(age_id)
 )
 
 CREATE TABLE statestik (
     id bigint NOT NULL,
     age_id NOT NULL,
     sex nvarchar(1) NOT NULL,
     PRIMARY KEY(id)
 )

Jeg er ikke verdens bedste til db, men nu har du hvilken retning jeg vil gå i.

(BASERET PÅ SQL SERVER 2005)

På nuværende tidspunkt har vi fire demografiske emner, som dækker over alder (specifikt), køn, postnr og sprog. Men vi skal videre ud og have mange andre mærkelige ting med.

Jeg har været ude i mange foreskellige setups.

Ovenikøbet med en tabel til hver information, hvilket ikke ser kønt ud, grundet de mange relationer - kan man komme ud over med hash-keys. Men heller ikke så kønt. hehe.

pseudokode er også fint nok, jeg blot finde den bedste bane at følge.

Det var da nogle lækre ideer... Lige nu leger jeg med tanken om at have en tabel hvor jeg samle alt, altså første normalform... Til analysen segmenteres det hele så efter hvad jeg skal bruge, grupperet efter applikation og demografi.
Det vil sige at jeg pt ender med fire tabeller for hhv. reklamer og nogle nyhedsområder. Der vil være en for hver demografisk type.

En tabel til at skrive i, og fire til at læse fra.

Tror i at den er helt ved siden af?

Jeg synes ikke det er en god ide. Normalt når man snakker om vertikal segmentering (opdeling af ens data i flere tabeller) gør man det typisk fordi der er for mange data i ens tabel og man begynder at tabe performance ud fra det.

Det er væsentligt hurtigere at lave en tabel med reklamer og så en fremmednøgle mod nyhedsområder, således kan du nå det hele med en enkelt forespørgsel, blot ved at joine. Det er langt den bedste løsning frem for at skulle opdele ens data (redundans).

Samtidig ved at beholde det i samme tabel undgår du problemer hvis din løsning udvider sig og du skal have opdelt dine områder i yderligere elementer eller have introduceret nogle yderligere dimensioner (nyhedsområder er en dimension - se evt. min artikel igen :-) ). Jeg er bange for at du kommer i for mange problemer med at opdele de samme data i flere tabeller. Der er ingen problemer med datamængder, her hvor jeg arbejder har vi lavet datawarehouses til analyser med mange 100.000 rækker og flere 1000 dimensionsrækker - ingen problemer, du trækker jo sjældent dem alle ud på een gang, men derimod kun et subset.

Jeg kan godt lide ideen med at have et forskelligt sæt tabeller (stage tabeller) til at behandle dine data i (opnå normalformen) fremfor at benytte det samme sæt tabeller til det hele, det er også en bedre løsning (kig evt. på sql server's DTS for at køre flere scripts på dine stagedatabaser med regulære intervaller)