Hej! Det basta (Om du har tid) ar att ga igenom det hela i lugn och ro och gora migreringen sjalv, mha exempelvis dts el. liknande. Det ar alltid saker som gar att gora battre nar man byter plattform. Varför fler än hundra tabeller? Vad i din datastruktur kräver detta? Därför att vi har många olika typer av uppgifter som lagras i databaser. Data som hänger samman ska ligga i samma databas, liksom procedurer och vyer etc. Data som ej hänger samman ska ligga i olika databaser. Det håller jag med om, men hur gör man när man behöver en vy som visar data från olika databser, typ vilka kunder har ordrar i detta projektet? (Uppdelat på kunder, ordrar och projekt, alltså olika databaser.) Det gör man inte, varje databas ska innehålla data som har en viss tillhörighet, och de vyer som behövs för denna data. Om du har två olika databaser med sammanhängande information så är det feldesignat i mina ögon. Alltså måste jag lägga alla tabeller, vyer och stored procedures i samma databas. Nja, det enda viset att 'gruppera' dem är genom att ge dem något prefix som gör att de presenters i grupp, t ex customerAdd, customerRemove, customerUpdate etc för några procedurer som har med kunddata att göra. Tack för informationen.Strategiska funderingar när det gäller migriation av Access till SQL-S
Jag håller på och testar migriation av Access till SQL-Server.
I Access har vi fler än hundra tabeller uppdelade logiskt i olika databaser, alltså olika mdb-filer.
Fråga 1. Ska jag göra på samma sätt i SQL-Server?
När jag har testat att köra updating wizard och skapa ett ADP-projekt (direktkopplat till SQL-Servern) så sparas alla vyer och stored procedures (skapade av wizarden) i en databas. Detta innebär att när jag uppdatera andra program (vi har ett trettital Access-program) så hamnar alla vyer och stored procedures i samma databas = en stor röra.
Fråga 2: Vad kan jag göra åt detta?
För att sammanfatta det hela.
Fråga 3: Vad är bästa strategierna när amn migrerar Access till SQL-Server med många olika databaser och program utan att få en stor röra och ändå behålla den logiska uppdelningen?
Tacksam för all hjälp.Sv: Strategiska funderingar när det gäller migriation av Access till S
Sv: Strategiska funderingar när det gäller migriation av Access till S
Sv: Strategiska funderingar när det gäller migriation av Access till S
Vi har för närvarande 165 tabeller i 36 Access-databaser, ett tjugotal kan säkert designas bort, men ska alla tabeller normaliseras till tredje formen så kommer det bli många fler, så antalet tabeller har väl ingen större betydelse.
Det jag bekymmrar mig över är att alla vyer och stored procedures hamnar i samma databas. Det blir svårt att hålla ordning på dem då.
Så jag undrar hur det ser ut på större projekt, ligger alla tabeller, vyer och stored procedures i en och samma databas?
Om inte, kan man på ett enkelt sätt göra kopplningar där mellan databaserna?
I Access är det enkelt att dela upp vyerna i olika program och bara länka in de tabeller som ska användas till programmet, men som jag förstår det så ska allt ligga i samma databas i SQL och då blir det väldigt mycket.
Jag börjar funderar på om det är värt mödan och tiden som kommer att krävas att göra detta projektet.Sv: Strategiska funderingar när det gäller migriation av Access till S
Sv: Strategiska funderingar när det gäller migriation av Access till S
Sv: Strategiska funderingar när det gäller migriation av Access till S
Sv: Strategiska funderingar när det gäller migriation av Access till S
Jag måste komma på en bra namnstandard.
Finns det något bra sätt att gruppera tabeller, vyer och stored procedures?Sv: Strategiska funderingar när det gäller migriation av Access till S
Sv: Strategiska funderingar när det gäller migriation av Access till S
Får se hur det går med migiriationen.