Få data fra 100+- databaser på samme server inn i koden

[RAD1V]

Si at man har oppimot 100+ kilder som sender data, for eksempel sensordata fra 100+ kjøretøy, så oppretter databaser med navn som db_1, db_2 osv.

 

Dette som et alternativ til å bruke samme database og skille mellom kilder med en verdi i tabellen.

 

 

 

Er dette en håpløs måte å gjøre det på? Om ikke; hvordan gjør man det med EF 5?(stikkord for hva jeg må lese opp på)

 

 

 

Er ikke min løsning, men løsningen det ser ut til jeg må bruke..

[terjeelde]

Hvis dette er forskjellige kunder eller "kunder", slik at data må være skilt fra hverandre av tilgangshennsyn, så kan det ha noe for seg.

 

Utover det vil jeg si at dette normalt burde ligge i samme database, men gjerne forskjellige tabeller, kanskje forskjellige skjema.

 

EF 5 vet jeg ikke hva er.

[Kamikaze-Kanin]

Siden det virker som om du har 100+ kilder til data av samme format så ville jeg valgt å ha alt i en database. En database er jo laget for å samle data, ikke separere det. På denne måten kan du enkelt lage spørringer som tillater deg å sammenligne data fra ulike kilder. Gå for én database, ikke vurder engang å separere kildene hvis ikke de har vidt forskjellige "bruksområder". Nå er det noen få år siden jeg modellerte EF, men bare tenk at kilden skal være en del av primærnøkkelen så kommer du langt

 

Hvis dette er forskjellige kunder eller "kunder", slik at data må være skilt fra hverandre av tilgangshennsyn, så kan det ha noe for seg.

 

Utover det vil jeg si at dette normalt burde ligge i samme database, men gjerne forskjellige tabeller, kanskje forskjellige skjema.

 

Prøv å samle så mye like data som mulig. Skal kunder ha tilgang til data, kan det opprettes views som kun tillater kunder å se egen informasjon. Er litt uenig med terje, vil ikke dele opp data i forskjellige tabeller når data er i samme format

[terjeelde]

Tror vi er enig, men jeg ordla meg dårlig. Jeg burde sagt "hvis det er krav fra kunde". I noen tilfeller trenger man å separere helt, f.eks hvis kunde skal ha direktetilgang til databasen, og man ikke får sperret mellom kunder på annet vis enn å separere i forskjellige databaser.

 

Helt enig i at data bør samles mest mulig.

[terjeelde]

Leste litt for fort... du skrev ikke skille tabeller. Sånn kan det gå når man skimmer ting på bussen.

 

I utgangspunktet enig også når det gjelder tabeller. Hvis det er store datamengder det er snakk om, så kan man evt. ønske å splitte i tabeller, og dele inn etter kunde, tid, eller begge deler.

 

I mange databaser kan man bruke et view eller sammenkoblede databaser for å få dette til å oppføre seg som en tabell.

 

Likevel, jeg ville ikke gjort det før du har et problem, hvor dette vil løse problemet.

 

Terje

[RAD1V]

Takk for raske svar!

 

Kan nokk bli 100k+ meldinger fra hver kilde. Ville det vært en dårlig idé å ha alt i én gigantisk tabell?

 

 

 

(EF 5 = Entity Framework 5)

[terjeelde]

Jeg kjenner som sagt ikke Entity Framework, men for de fleste databaser er noen hundre tusen meldinger veldig, veldig lite.

[RAD1V]

Selv ganget med 100(kilder) er det ikke nødvendig å spre dataen over 100 databaser av den grunn?

 

Tror du dette forumets 20 millioner innlegg er i samme tabell?

[terjeelde]

Kanskje like greit å vise, heller enn å bare si...

Jeg har en demo-side jeg lagde for en tid tilbake. Den logger rundt en halv million rader pr. år, pr. sensor. Hvis du besøker denne linken, så henter den ut ca. ti tusen rader for å lage grafen:

http://restdemo.keepquiet.net/

Som du kan se der, så er dette ganske små datamengder, som ikke er noe tregt å flytte rundt på.

 

Ofte er det ikke mengden ting på en plass som er problem med databaser, men hva du gjør med dem. F.eks å sette inn mange nye ting på kort tid. Dette vil gjerne være enklere i en database, enn i mange.

 

Samme med minne-bruk. Dette kan være et problem med veldig store datamengder, men man tjener ikke automatisk noe der heller på å bruke flere databaser.

 

Når det gjelder forumet her, så kan det godt være de kjører alt i en tabell. Det er som sagt ikke veldig store mengder data vi snakker om. Selv ville jeg gjerne delt inn i en tabell pr. år eller kvartal, for å bare la noenlunde nye ting ligge altivt i minne.

(men limt tabellene sammen med et view, så jeg kunne jobbe mot det som om det var en tabell).

[siDDis]

nei, nei og atter nei!

 

All dataen puttes i 3 tabeller i ein database!

 

F.eks:

Verdier

VERDI, SENSOR_ID, BIL_ID

 

Sensor

SENSOR_ID, TITTEL, BESKRIVELSE

 

Bil

BIL_ID, TITTTEL, BESKRIVELSE

 

Gjer du det på ein anna måte, så gjer du det feil. Du kan milliarder av milliarder av rader inni ein tabell.

 

EDIT:

 

Verdier burder være

VERDI, SENSOR_ID, BIL_ID, DATOSTEMPEL

[terjeelde]

Om det var uklart fra min side: jeg mente for gudsskyld ikke at trådstarter skulle presse *alt* data inn i en tabell, bare at det var unødvendig å splitte det som hører hjemme i en.

Tilsvarende for forumet her. De kjører nok ikke *alt* data i en tabell, men det kan godt tenkes alle innleggende er i en.

Endret 27. mai 2013 av terjeelde

[quantum]

nei, nei og atter nei!

 

Jeg er helt enig, med ett forbehold, og det er hvis f.eks. kunde eller myndigheter krever det av en eller annen grunn, sensitivitet f.eks., det er jo allerede nevnt. Det kan jo også være praktisk dersom enkeltkunder eller "sensorer" vil ha en dump av sine data, det blir jo da en del enklere, men må veies opp mot å ha 100+ databaser å holde styr på ifm. backup, skjemaendring osv.

 

Siden EF er i bruk antar jeg det ligger en .net-app på toppen og styrer med tilgang, autentisering osv?