Hej,

Har fått frågan om .Net framework som utvecklingsmiljö i ett projekt kan hantera lokala & centrala databaser. Jag kan själv inte se att det skulle vara problem att bygga en applikation som använder sig av flera databaser.

Men frågan är finns det någon här med erfarenhet av det? Som kan dela med sig av dessa.

Nu handlar det inte om små databaser utan om terabyte stora sådana och flera hundra som samma applikation skall arbeta mot. Dessa skall sedan placeras lokalt och centralt.

Jag vill ha erfarenheter posetiva som negativa. Inga lösningar på problem alltså.

Någon som arbetat med replikering av data, typ en lokal databas när användaren som innehåller det som är unikt för en grupp av användare och sedan en central databas som innehåller data som delas av flera grupper av användare. (Detta replikeras sedan ut till de lokala databaserna).

Synpunkter och erfarenheter mottages tacksamt på hur .Net som utvecklingsmiljö funkar i dessa senarios

Roger

Precis som du säger så är det inte direkt problem, det du bör tänka på är hur du vill bygga upp arkitekturen och hantera pekare mot databaserna (ex connectionstrings hantering).

Sedan hanterar du allt via Data Lagret, det är där du går mot de olika datakällorna som du vill nyttja och låta Busines Lagret hantera datan åt dig.

De negativa vs Possetiva bitarna beror helt o hållet på syfte och dess mål. Arkitekturmessigt kan i alla fall inte jag säga vad det är som är negativt då jag inte vet hur det skall sättas ihop m.m. Vi kör själva mot flera databaser stora som små och de problem som dock kan ha uppstått är kommunikation mellan utvecklare, då många ansvarar för olika dbs kan det lätt med bristande kommunkation resultera i att ändringar i de flytande databaserna uppstår och kan på så vis förstöra för din applikation. En lokal db som du ansvarar för har just du bättre kontroll över. Oftast ger flera dbs bara possetiva saker, ex skalbarhet, prestanda. Ökad modularitet.

Andra fördelar med flera DBs är om du skall göra uppdateringar, så behöver du ev bara stänga av "vissa" delar av din applikation. Det meför att du inte behöver ha en 100% downtime. Värre är det om de olika databaserna pratar med varandra via exempelvis Stored Procedurer, det är inte rekomenderat att bygga på det sättet.

Ett tips är bara att ha flytande kommunikation mellan de som administrerar och nyttjar databaserna förutom dig själv.


Mvh Johan

Det låter som att du måste blanda in COM+ i ditt projekt. Och det beror på att .NET isig själv inte klara av Transactioner till 2 eller flera databaser, och det kommer du säkert stötta på.

Alltså att du måste kunna vara säker på att Förändringen i databas 1 bara blir genomför om det även går bra till databas 2. Och det är då du skall använda dig av Transactioner, och för att lösa det över flera databaser så behövs COM+.

Helt plötsligt växte ditt projekt en smula :) Skall du dock endast läsa, eller endast förändra i 1 databas så behöver du inte COM+.

- M

Om det kommer att vara två databaser så tror jag att anledningen kommer vara att man vill placera central data i en central databas och den lokala en en lokal databas nära applikationen. Alternativt så används replikering och i båda dessa fall stöter vi inte på problemet...

Roger

Man måste inte ha Com+ för att man kör med flera databaser om de inte skall ingå i en CUD(Creat,Update,Delete) process. Alltså om du skall spara data från ett gränsnitt och du måpste spara i olika dbs innan din process är klar så är ju transaktioner att rekomendera. Dock inget måste det avgör du själv med tanke på feltolleransen du sätter upp för ditt projekt. Om du bara skall hämta data från flera db men updatera en åt gången (alltså inte vara beroende av flera stycken under en Business Process) så behöver du inte bry dig om transaktioner med Enterprise services. Då räcker det att du kör dem i SP nivå eller genom ADO .Net.

Allt handlar i grund och botten Hur man skall nyttja databaserna. Det är där kraven sätts och det är utifrån dem du sedan får avgöra vilken teknik du måste ha.

Mvh Johan

Som jag misstänkte då. Egentligen inga problem. Finns det någon anledning att dela datalagret på två måntro?! Typ ett lager för att hantera kopplingen till databasen och ett som tar hand om själva transaktionerna.

Ett senario skulle kunna vara att de centrala databaserna är Oracle och de lokala MS SQL servrar. Vet någon hur Oracle Providern är i 1.1?! Funkar den bra?

Roger