Alternativen är som standard OFF eftersom, med all sannolikhet, denna databas skapades och skriptades utan att beröra någon av standardinställningarna. När en databas skapas klonas den i huvudsak från model systemdatabas, och på en helt ny installation av SQL Server kommer ANSI-inställningarna på databasen att vara OFF , även om vissa av dessa inställningar (som ANSI_NULLS ) är alternativ som du verkligen aldrig skulle vilja vara OFF för alla moderna databasapplikationer. Faktum är att i fallet med ANSI_NULLS i synnerhet specificerar dokumentationen att möjligheten att överhuvudtaget stänga av den är fasad
, även om det troligen fortfarande kommer att dröja några år innan det verkligen är fallet.
Och däri ligger problemet:dessa inställningar hålls fortfarande OFF till förmån för gamla applikationer, som var tvungna att aktivera dessa alternativ ON långt tillbaka när att dra nytta av deras godhet (och bryta förändringar). Om sessionen inte anger några värden för dem tillämpas databasinställningarna.
Men de flesta applikationer gör ange dessa inställningar i en session, om inte explicit, så implicit genom deras dataåtkomstbibliotek. Enligt dokumentationen på SET ANSI_DEFAULTS
, som växlar en massa inställningar på en gång:
DB-Library är ett gammalt åtkomstbibliotek som fortfarande används av en del uråldriga applikationer och eventuellt som en stödkälla för saker som FreeTDS, så då och då kan du fortfarande stöta på ett program som avsiktligt eller av misstag använder databasinställningarna, men detta är allt mer sällsynt.
När det gäller det bästa värde för dessa alternativ, det beror helt på ditt användningsfall. Om du måste stödja gamla applikationer som förväntar sig gammalt beteende, kanske du inte har något val att behöva lämna databasinställningarna på OFF . Om du har en applikation som ansluter via ett gammalt bibliotek men verkligen förväntar dig modern SQL-semantik, kanske du vill aktivera dem ON . För alla andra applikationer är dessa alternativ troligen redan inställda på per-session-basis till sina (in)korrekta värden av applikationen själv och vad du konfigurerar spelar ingen roll ändå.
En diskussion om varje enskilt alternativ och när du vill aktivera det ON eller OFF skulle överskrida gränserna för ett rimligt svar. Läs dokumentationen om var och en av dem och formulera dina egna bästa praxis. Du kan låta saker som SET alternativkrav för index på beräknade kolumner
guidar dig, som kräver en massa alternativ för att vara ON innan du ens kan skapa dem (och de anses allmänt vara trevliga att ha).