Önskar synpunkter varför man INTE ska husera flera databaser i samma databas. (alltså inte flera databaser i samma databasserver utan en databas i samma server) Vi har en legacy namngivning på tabeller med AppName_tabell(DBName_tabell), med motivering att man måste kunna köra alla appars tabeller i samma databas. Vilket jag är helt emot av flera anledningar, vill gärna höra era.

Börjar med lite egna synpunkter, som ni kan kommentera.

En databas eller flera databaser!?

Många tabeller/vyer/SP's i en databas "eller" flera databaser med tabeller/vyer/SP's lågiskt/transaktionsmässigt tillhörande varandra.
Nedan listas argument varför man alltid ska ha flera databaser i en databasserver.

* Prestanda
(Ingen prestanda förlust med flera databaser, däremot möjligheter till prestandaförbättringar.)
(DBServern har mycket liten(försumbar) overhead att ha många databaser. Den cachar pages av tabeller och inte hela databaser.)

* Transaktionssäkerhet
(tabeller som lågiskt/transaktionsmässigt tillhör varandra, delas i olika databaser, även fast de behövs från en app.)
(Tex. Har du fem "order ifyllnad" tabeller, fyra "order leverans" och tre för "order personer" bör det vara i tre databaser.)

* Transaktionsintegritet
(Vid återläsning av backup, behöver databasen tas offline. Då bara transaktionsmässigt gemensamma tabeller ligger i en databas, kan de andra vara igång.)
(Hade alla tabeller legat i samma databas, hade det lett till onödig förlust av data för andra tabeller. Det går att återställa per tabell, men tar lång tid, då du måste skriva vilka tabeller som avses.)

* Informationssäkerhet
(Enklare att administrera rättigheter på databas nivå. Mindre risk för att information själs från annan tabell.)
(Tex. personer som handhar godkännande/support av "order personer", behöver bara läsrättighet i "order leverans".)

* Filsäkerhet
(Enklare att flytta databasfiler till nya diskar och ha dem på olika diskar.)

* Prestandabalansering
(Enklare att sätta upp tunga databaser, så de får den bästa hårdvaran.(CPU, Minne, I/O,..))

<b>>* Prestanda
(Ingen prestanda förlust med flera databaser, däremot möjligheter till prestandaförbättringar.)
(DBServern har mycket liten(försumbar) overhead att ha många databaser. Den cachar pages av tabeller och inte hela databaser.) </b>
Nja, har man vyer så kan de väl inte ha schemabinding om det ligger på olika databaser (i SQL-server), och där kan man då få vansinnigt dålig prestanda?

(edit)
I den inbyggda editorn för vyer går det inte att få dit tabeller från andra databaser, men i en query-fönster går det att skapa vyer mellan databaser, även mellan databaser på olika servers. När man väl fått till vyn, går det sedermera att ändra i designläget.

http://msdn.microsoft.com/en-us/library/ms187956.aspx

[code]
--Partitioned view as defined on Server1
CREATE VIEW Customers
AS
--Select from local member table.
SELECT *
FROM CompanyData.dbo.Customers_33
UNION ALL
--Select from member table on Server2.
SELECT *
FROM Server2.CompanyData.dbo.Customers_66
UNION ALL
--Select from mmeber table on Server3.
SELECT *
FROM Server3.CompanyData.dbo.Customers_99
[/code]

Öh, vad stod det före edit?
Poängen är just schemabinding, som gör all the difference.

[Niklas]
Kan du utveckla vad du menar med att man inte kan schemabinda från olika databaser.

Infogade länk och kodexempel.

Har inte i MSSQL provat att joina flera databaser, borde vara vanligt, om inte MSSQL har dåliga prestanda på det, har du sådana erfarenheter?

Har kört mot två databaser med DB2, och där var det inga problem. Det var en databas för mätvärden(+50GB) och en för metadata om mätpunkter och kunder(~1GB). Uppdelningen var naturlig, då mätdatat partitionerades på andra diskar och fick eget dedicerat minne, så den inte skulle svälta ut metadatabasen.

Jonas det du skriver fungerar utmärkt på SQL Server.
Även det som Niklas hade funderingar/invändningar (om jag förståt det rätt) fungerar utmärkt.

Ok tack, misstänkte väl det, då det i verkliga applikationer är vanligt, så borde ju inte MSSQL ha problem med det.