Serwer SQL: konwencje nazewnictwa schematu

Question

Należy rozważyć serwer bazy danych, którego zadaniem jest obecnie przechowywanie jednej bazy danych. Prawdopodobnie baza danych zostanie przeniesiona w przyszłości do innej instancji bazy danych, która zawiera wiele schematów baz danych &.

Załóżmy, że aplikacja/projekt nosi nazwę Invoicer 2.0. Baza danych nazywa się AcmeInvoice. Baza danych zawiera wszystkie informacje o fakturze, kliencie i produkcie. Oto schemat aktorów, ich ról i zachowań.

Schemat (-y) będzie w dużej mierze być stosowany do łatwo przypisać uprawnienia do ról. Dodatkową korzyścią jest to, że obiekty nie znajdują się pod dbo, a uprawnienia obiektów mogą zostać przeniesione na inną maszynę w przyszłości.

Pytanie

• Co konwencje używacie podczas nazywania schemacie?
• Czy dobrze jest nazwać schemat tak samo jak bazę danych?

Answer 1

Sądzę, że jeśli nazwa twojego schematu kończy się na tym samym, co schemat bazy danych, dodajesz do bazy danych nadmiarowość. Znajdź obiekty w bazie danych, które mają wspólny zakres lub cel i utwórz schemat, aby ponownie wybrać ten zakres. Na przykład, jeśli masz podmiot do faktur i masz kilka tabel wyszukiwania uzupełniających dla stanów faktur, itd., Umieść je wszystkie w schemacie faktur.

Jako ogólną zasadę, staram się unikać używania nazwy, która odzwierciedla nazwę aplikacji, nazwę bazy danych lub inne konkretne/fizyczne rzeczy, ponieważ mogą się one zmienić, i znaleźć nazwę, która koncepcyjnie reprezentuje zakres twoich obiektów to wejdzie w schemat.

Twój komentarz stwierdza, że ​​"schematy będą w dużej mierze wykorzystywane do łatwego przydzielania uprawnień do ról". Twój diagram pokazuje konkretne typy użytkowników mających dostęp do niektórych/wszystkich tabel lub niektórych/wszystkich przechowywanych proc. Myślę, że próba uporządkowania obiektów w schematy i uporządkowania ich z punktu widzenia bezpieczeństwa w schematy są sprzeczne. Opowiadam się za tworzeniem ról w serwerze sql w celu odzwierciedlenia typów użytkowników i nadania tym rolom dostępu do konkretnych obiektów, które każdy typ użytkownika potrzebuje, w taki sposób, aby przyznać rolę lub użytkownikowi dostęp do schematu w celu zbudowania struktury bezpieczeństwa.

Answer 2

Dlaczego nazwa schematu jest taka sama jak w bazie danych? Oznacza to, że wszystkie obiekty bazy danych objęte są tym samym schematem. Jeśli tak, to dlaczego w ogóle masz schemat?

Zazwyczaj schematy służą do grupowania obiektów w ramach wspólnego zakresu czynności lub funkcji. Na przykład, biorąc pod uwagę to, co opisałeś, możesz mieć schemat faktury, schemat klienta i schemat produktu. Wszystkie obiekty powiązane z fakturą zostaną umieszczone w schemacie faktury, wszystkie obiekty związane z klientami zostaną umieszczone w schemacie klienta, a to samo w przypadku produktów.

Często używamy również wspólnego schematu, który obejmuje obiekty, które mogą być wspólne dla całej naszej aplikacji.

Answer 3

Nazwałbym bazę danych AcmeInvoice (lub inną odpowiednią nazwą) i schematem Invoicer2.

Moje powody są następujące: Acmeinvoice oznacza, że ​​grupuję wszystkie te aplikacje/dane razem. Można go zatem przenieść jako jedno urządzenie do innych maszyn (tworzenie kopii zapasowej/przywracanie lub odłączanie/dołączanie).

Schemat będzie Invoicer2. Aplikacje się zmieniają, może w przyszłości będziesz mieć Invoicer21 (możesz utworzyć schemat) lub moduł lub system raportowania (Schemat raportów). Uważam, że użycie schematów pozwala mi rozdzielić dane/procedury w jednej bazie danych na różne grupy, które ułatwiają administrowanie uprawnieniami.