De ce numele tabelelor din SQL Server încep cu „dbo”? (Programare, Server Sql)

pupeno a intrebat.

Cel puțin pe instanța mea locală, atunci când creez tabele, toate sunt prefixate cu „dbo.”. De ce se întâmplă asta?

Comentarii

4 răspunsuri
Daniel

dbo este schema implicită în SQL Server. Puteți crea propriile scheme pentru a vă permite să vă gestionați mai bine spațiul de nume al obiectelor.

Comentarii

    24

  • Ca o bună practică, adaug întotdeauna prefixul „dbo.”, chiar dacă nu este necesar. De cele mai multe ori, în SQL este bine să fii explicit. –  > Por SurroundedByFish.
  • @SurroundedByFish: Probabil că nu este o bună practică, dar s-ar putea să mă înșel, deoarece nu sunt expert SQL. stackoverflow.com/a/769639/602245 –  > Por Brett.
  • Acest articol de la un alt răspuns susține că este de fapt o bună practică: „Codul nu ar trebui să utilizeze numele complet calificat, deși există un ușor câștig de performanță dacă se face acest lucru și este considerat o bună practică. ” –  > Por Carl G.
  • De asemenea, răspunsul pe care l-ați linkat recomandă, de asemenea, includerea „dbo.”, astfel încât optimizatorul să nu fie nevoit să caute schema. –  > Por Carl G.
  • dbo nu este o practică bună. Creați-vă propria schemă și folosiți-o întotdeauna. dbo există doar un truc de migrare, astfel încât pre-SQL Server 2005 continuă să funcționeze. Da, folosiți întotdeauna o schemă pentru perf. Nu, nu cea de migrare (de exemplu, dbo). –  > Por David Betz.
Fenton

Dacă utilizați Sql Server Management Studio, puteți crea propria schemă navigând la Databases – Your Database – Security – Schemas.

Pentru a crea una folosind un script este la fel de simplu ca (de exemplu):

CREATE SCHEMA [EnterSchemaNameHere] AUTHORIZATION [dbo]

Le puteți utiliza pentru a vă grupa logic tabelele, de exemplu, creând o schemă pentru informații „Financiare” și alta pentru date „Personale”. Tabelele dvs. s-ar afișa apoi ca:

Financial.BankAccountsFinancial.TransactionsPersonal.Address

În loc să folosiți schema implicită dbo.

Comentarii

  • Știți dacă acest lucru cauzează vreo problemă atunci când folosim Entity framework? –  > Por Emil.
  • Puteți utiliza schemele cu Entity Framework – chiar și cu cod mai întâi, dacă doriți: [Table("Customer", Schema = "MySchema")] –  > Por Fenton.
  • ‘AUTORIZATION [dbo]’ acordă aceleași permisiuni ca și dbo pe schemă, sau trebuie să mai acord permisiuni utilizatorilor? –  > Por Mark Micallef.
Jaans

Este un element nou în SQL 2005 și oferă o modalitate simplificată de grupare a obiectelor, în special în scopul securizării obiectelor din acel „grup”.

Următorul link oferă o explicație mai aprofundată despre ce este, de ce l-am folosi:

Înțelegerea diferenței dintre proprietarii și schemele din SQL Server

Manngo

Microsoft a introdus schema în versiunea 2008. Pentru cei care nu știau despre scheme și pentru cei cărora nu le păsa, obiectele au fost introduse într-o schemă implicită dbo.

dbo înseamnă DataBase Owner (proprietar de bază de date), dar acest lucru nu este foarte important.

Gândiți-vă la o schemă ca la un dosar pentru fișiere:

  • Nu este nevoie să faceți referire la schemă dacă obiectul se află în aceeași schemă sau în schema implicită.
  • Puteți face referire la un obiect dintr-o schemă diferită folosind schema ca prefix, la fel cum puteți face referire la un fișier dintr-un dosar diferit.
  • Nu puteți avea două obiecte cu același nume într-o singură schemă, dar puteți avea în scheme diferite.
  • Utilizarea schemelor vă poate ajuta să organizați un număr mai mare de obiecte.
  • Schemele pot fi, de asemenea, atribuite anumitor utilizatori și roluri, astfel încât să puteți controla accesul la cine poate face ce.

Puteți accesa întotdeauna orice obiect din orice schemă.

Deoarece dbo este implicită, în mod normal nu este necesar să o specificați în cadrul unei singure baze de date:

SELECT * FROM customers;
SELECT * FROM dbo.customers;

înseamnă același lucru.

Înclin să nu fiu de acord cu ideea de a utiliza întotdeauna dbo. prefix, deoarece cu cât vă aglomerați mai mult codul cu detalii inutile, cu atât este mai greu de citit și de gestionat.

În cea mai mare parte, puteți ignora schema. Cu toate acestea, schema va deveni evidentă în următoarele situații:

  1. Dacă vizualizați tabelele fie în navigatorul de obiecte, fie într-o aplicație externă, cum ar fi Microsoft Excel sau Access, veți vedea dbo. prefixul. Îl puteți ignora în continuare.

  2. Dacă faceți referire la un tabel dintr-o altă bază de date, veți avea nevoie de numele complet al acestuia sub forma database.schema.table:

    SELECT * FROM bookshop.dbo.customers;
    
  3. Din motive istorice, dacă scrieți o funcție scalară definită de utilizator, va trebui să o apelați cu prefixul schemei:

    CREATE FUNCTION tax(@amount DECIMAL(6,2) RETURNS DECIMAL(6,2) AS
    BEGIN
        RETURN @amount * 0.1;
    END;
    GO
    SELECT total, dbo.tax(total) FROM pricelist;
    

    Acest lucru nu se aplică altor obiecte, cum ar fi funcțiile de tabel, procedurile și vizualizările.

Puteți utiliza schema pentru a depăși conflictele de denumire. De exemplu, dacă fiecare utilizator are o schemă personală, acesta poate crea obiecte suplimentare fără a fi nevoit să se lupte cu alți utilizatori pentru denumire.