MSSQL by Wilfred

Onlangs kwam een ontwikkelaar naar mij met met de volgende vraag: " Ik probeer een foreign key constraint te leggen tussen 2 tabellen, maar de aanmaak ervan lukt mij niet. Ik wijs naar een identity kolom, maar SQL klaagt dat deze kolom niet als uniek is gedefinieerd. Maar een identity kolom geeft toch altijd unieke waarden? " Laten we eens naar de melding kijken, welke MSSQL terug geeft. Met onderstaande code is het probleem te reproduceren. De tabel dbo.vader heeft wel een PRIMARY KEY, maar deze werd niet gebruikt in de FOREIGN KEY definitie (omdat de primary key eigenlijk uit meerdere kolommen bestond, maar ik heb het voorbeeld eenvoudig gehouden): use tempdb go create table dbo.vader(id uniqueidentifier primary key, sub_id int identity(1,1), naam varchar(16)) go create table dbo.zoon(id uniqueidentifier primary key, id_vader int references dbo.vader(sub_id)) go Het uitvoeren van deze code geeft de volgende foutmelding: Msg 1776, Level 16, State 0, Line 6 There are no pr

Security is een belangrijk item bij de bescherming van je data. Met security voorkom je verlies, verminking, gijzeling of diefstal van je data. Daarom is het belangrijk dat alle noodzakelijke maatregelen genomen worden om je data veilig te stellen. Security bestaat uit een aantal lagen: wie ben je? (Authenticatie) wat mag je? (Autorisatie) Het securitymodel van MSSQL kun je vergelijken met een huis; de instance is het huis en de databases zijn kamers in het huis. Authenticatie mogelijkheden Het account waarmee je je aanmeldt op een instance noemen we een login. Dit account geeft je toegang tot de voordeur van het huis. Je hebt naast toegang tot de instance ook apart toegang nodig tot een of meerdere databases (kamers). MSSQL kent 2 authenticatie mogelijkheden: aanmelden met je domein account aanmelden met een account wat binnen MSSQL is gedefinieerd Aanmelden met je domein account Je domein account gebruiken als login heeft de voorkeur, omdat dan een aantal zaken niet door MSS

Dit artikel gaat over aanpassingen aan de database structuur welke de performance kunnen verbeteren. De aanpassingen betreffen de inrichting van filestructuur en de daarbij behorende zaken. Disclaimer: Alhoewel onderstaande aanbevelingen de performance verbeteren, moet de onderliggende applicatie wel overweg kunnen met deze aanpassingen. Het zelf aanpassen van de database structuur zonder te weten of de applicatie vervolgens nog functioneert geeft grote risico's. Raadplaag in dat geval dan ook altijd eerst de leverancier. Mountpoints Traditioneel zijn er schijven gekoppeld aan een server, welke allemaal een driveletter krijgen. Met de huidige virtualisatie is dit soms niet meer wenselijk of zelfs mogelijk. We spreken in een virtuele omgeving ook niet meer over disken, maar over volumes. Volumes worden tegenwoordig niet meer gekoppeld als driveletter, maar als mountpoint. Veelal is dit mountpoint als directory gekoppeld; het lijkt dan of je in een directory staat, maar feitelijk ben

Een veel gestelde vraag op SQL forums is of er backups van MSSQL databases gemaakt kunnen worden zonder de ruimte die indexen gebruiken. Het voordeel hiervan is dat de backup korter duurt en dat de backupfile kleiner wordt. Nadeel is dat je na een restore van zo’n backup de indexen handmatig moet toevoegen; je bent dus tijd kwijt aan de creatie van de indexen en je moet dus ook de creatie scripts hebben. Het blijkt niet mogelijk om met het backup commando een optie mee te geven om indexen uit te sluiten van de backup. Er wordt weleens geopperd om de indexen in een aparte filegroup te plaatsen en deze filegroup dan uit te sluiten van de backup, maar dat geeft behoorlijk wat nawerk, mocht deze backup worden gebruikt voor een restore. Het blijkt mogelijk om indexen ook te kunnen disablen . Dit betekent dat de indexen niet meer bijgewerkt worden en niet meer worden gezien door de optimizer. De definitie van de indexen verdwijnt echter niet uit de database. Ook kunnen ge-disable indexen een