Kryteria decyzyjne dotyczące tego, kiedy użyć schematu innego niż dbo w porównaniu z nową bazą danych

Jestem głównie programistą aplikacji, ale muszę wykonać całą wstępną pracę z bazami danych dla mojego obecnego projektu (między innymi … MS SQL Server 2008 ). Jako pierwszą decyzję próbuję dowiedzieć się, czy podzielić swój stan za pomocą oddzielnych baz danych, czy też używając oddzielnych schematów w tej samej bazie danych. Przeczytałem trochę na temat schematów SQL Server i wydaje się to naturalnym sposobem oddzielania domen obiektów ( co lubię ), ale nie jestem pewien, czy mogą istnieć ukryte koszty tego wzorca.

Jakie są bardziej praktyczne rzeczy, które powinienem rozważyć przy wyborze między tymi dwoma podejściami? Jeśli dbo.mytableuniknę tego, myschema.mytableczy będę tworzyć inne wyzwania ( lub problemy ) dla mojej architektury?

Na marginesie ... W pewnym momencie zostanie to przekazane prawdziwemu DBA w celu utrzymania / wsparcia, więc staram się upewnić, że nie utrudniam ich życia.

Zacznę od stwierdzenia, że ​​nie traktuj schematów jako przestrzeni nazw lub domen obiektów w sensie OO. Schematy to zasadniczo kontenery uprawnień z pewną wartością dodaną (patrz poniżej)

Ponadto „osobne schematy” lub „osobne bazy danych” to 2 różne pojęcia. Dane, które muszą być spójne transakcyjnie i referencyjnie, muszą znajdować się w tej samej bazie danych. Zobacz jedną bazę danych czy dziesięć? artykuł na blogu, aby uzyskać więcej.

W tej bazie danych możesz lub nie możesz używać schematów do organizowania swoich obiektów.

Osobiście jestem fanem schematów i zawsze ich używam, ale do takich rzeczy jak uprawnienia i logiczne grupowanie. W tym celu odsyłam do poprzednich pytań, w których można zobaczyć ogólną opinię na ich korzyść:

• Projektowanie schematu - najlepsze praktyki?
• Jakiego standardu należy przestrzegać, nazywając tabele i widoki?
• Nadużywanie / prawidłowe używanie schematów?

W przypadku oddzielnych baz danych zobacz odpowiedź Aarona , ale wszystko to zależy od wymogu „spójnego transakcyjnie i referencyjnego”.

Zgadzam się z @gbn. Zaprojektowałem rozwiązania wykorzystujące schematy do separacji i bazy danych do separacji i uważam, że korzystanie z baz danych jest znacznie bardziej praktyczne. Kilka powodów:

1. Łączenie aplikacji z kontekstową bazą danych, a następnie uruchamianie tych samych zapytań jest znacznie łatwiejsze niż wstawianie zapytań <schema>przed wszystkimi odwołaniami do obiektów. Daje to wiele dynamicznego SQL, wiele różnych loginów aplikacji z domyślnymi schematami (co oznacza, że ​​Twój kod nie używałby prefiksu schematu, opierając się na domyślnym schemacie użytkownika aplikacji - może to prowadzić do masowego buforowania planu i trudnego debugowania), lub wiele procedur przechowywanych do zarządzania (wyobraź sobie prosty raport, jeśli potrzebujesz jednego na schemat, wtedy kod się zmienia, teraz musisz zmienić ten sam kod wiele razy, raz dla każdego schematu).
2. Rozdzielanie według bazy danych umożliwia elastyczność przenoszenia zajętych baz danych do szybszych lub różnych pamięci / instancji bez konieczności zgrywania obiektów z jednej dużej, wszechstronnej bazy danych. Większość ludzi nie myśli o tym tak wcześnie, ale jest to z pewnością potencjalny problem skali. Zwłaszcza jeśli skończysz z jednym schematem, który „przejmuje” i wymaga większości zasobów na serwerze, rozdzielenie ich może być niezwykle uciążliwym zadaniem, nawet jeśli są one już rozdzielone schematem.
3. Oddzielne bazy danych mogą również umożliwiać różne harmonogramy konserwacji i tworzenia kopii zapasowych dla każdego działu. Nie jestem pewien, co rozumiesz przez „dzielenie według stanu”, ale zakładając, że masz na myśli izolowanie klientów, możesz mieć klientów o różnych wymaganiach i różnej tolerancji na utratę danych, utrzymanie indeksu itp.
4. Możesz skończyć z klientami, którzy zgodnie z prawem lub polityką korporacyjną wymagają od Ciebie oddzielenia ich danych od innych osób. Jest to zazwyczaj dopuszczalne na poziomie bazy danych, ale poziom schematu zwykle będzie niewystarczający. Możesz nie mieć tych klientów teraz, ale może to stać się poważnym problemem później.