SQL Server şemaları ne işe yarar?

SQL veritabanlarını ve özellikle SQL Server'ı kullanmaya yeni başlamam. Ancak, öncelikle bir SQL 2000 adamıyım ve 2005 + 'da şemalar tarafından her zaman kafam karıştı. Evet, bir şemanın temel tanımını biliyorum, ama bunlar tipik bir SQL Server dağıtımında gerçekten ne için kullanılıyor?

Her zaman varsayılan şemayı kullandım. Neden özel şemalar oluşturmak isteyeyim? Dahili şemalardan herhangi birini neden atayım?

EDIT: Açıklığa kavuşturmak için, sanırım şemaların faydalarını arıyorum. Sadece bir güvenlik şeması olarak kullanacaksanız, veritabanı rolleri zaten .. er .. um .. rolünü doldurmuş gibi görünüyor. Ve bir ad alanı belirleyicisi olarak kullanmak, sahiplikle yapabileceğiniz bir şey gibi görünüyor (kullanıcıya karşı dbo, vb.).

Sanırım ne elde ediyorum, şemalar sahipler ve rollerle yapamadığınız ne yapıyor? Özel avantajları nelerdir?

Şemalar mantıksal olarak tabloları, prosedürleri, görünümleri birlikte gruplandırır. employeeŞemadaki çalışanla ilgili tüm nesneler vb.

Ayrıca, yalnızca bir şemaya izin verebilirsiniz, böylece kullanıcılar yalnızca eriştikleri şemayı görebilir ve başka hiçbir şey göremezler.

Tıpkı C # kodlarının Ad Alanı gibi.

Eklenti verileri için bir tür adlandırma çarpışma koruması da sağlayabilirler. Örneğin, SQL Server 2008'deki yeni Veri Yakalamayı Değiştir özelliği, kullandığı tabloları ayrı bir cdc şemasına yerleştirir. Bu şekilde, bir CDC tablosu ile veritabanında kullanılan gerçek bir tablo arasındaki bir adlandırma çakışması konusunda endişelenmek zorunda kalmazlar ve bu nedenle gerçek tabloların adlarını kasıtlı olarak gölgeleyebilirler.

Eski bir iş parçacığı olduğunu biliyorum, ama kendimi şemalara baktım ve aşağıdakilerin şema kullanımı için iyi bir aday olabileceğini düşünüyorum:

Bir Datawarehouse'da, farklı kaynaklardan gelen verilerle, her kaynak için farklı bir şema kullanabilir ve ardından şemalara dayalı olarak erişimi denetleyebilirsiniz. Ayrıca, başka bir poster yukarıda yanıtlandığı gibi, çeşitli kaynak arasındaki olası adlandırma çarpışmalarını önler.

Şemanızı ayrı tutarsanız, belirli bir şemayı yeni bir DB sunucusuna dağıtarak bir uygulamayı ölçeklendirebilirsiniz. (Bu, farklı işlevselliğe sahip olacak kadar büyük bir uygulama veya sisteminiz olduğunu varsayar).

Bir örnek olarak, günlük kaydı yapan bir sistemi ele alalım. Tüm günlük tabloları ve SP'ler [günlük kaydı] şemasındadır. Günlüğe kaydetme iyi bir örnektir, çünkü sistemdeki diğer işlevlerin günlüğe alma şemasındaki nesnelerle çakışması (eğer varsa) nadirdir.

Bu tekniği kullanmak için bir ipucu - uygulamanızdaki / sisteminizdeki her şema için farklı bir bağlantı dizesi kullanın. Ardından, şema öğelerini yeni bir sunucuya dağıtır ve ölçeklendirmeniz gerektiğinde bağlantı dizenizi değiştirirsiniz.

Brent ile bu konuda hemfikirim ... buradaki tartışmaya bakın. http://www.brentozar.com/archive/2010/05/why-use-schemas/

Kısacası ... şemalar, çok özel kullanım durumları dışında son derece yararlı değildir. İşleri dağınık hale getirir. Eğer yardım edebiliyorsanız bunları kullanmayın. Ve K (eep) I (t) S (uygula) S (aptal) kuralına uymaya çalışın.

Şemalara bağlı kullanıcıları diğer adlarla paylaşmanın faydasını görmüyorum. İşte nedeni ...

Çoğu kişi kullanıcı hesaplarını başlangıçta rollerle veritabanlarına bağlar. Herhangi bir biçimde sysadmin'e veya db_owner veritabanı rolüne bir kullanıcı atar atamaz, bu hesap "dbo" kullanıcı hesabına takma olarak veya tam veritabanı izinleri. Bu gerçekleştiğinde, kendinizi varsayılan şemanızın ötesinde (kullanıcı hesabınızla aynı ada sahip) bir şemaya nasıl atadığınıza bakılmaksızın, bu dbo hakları, kullanıcı ve şemanız altında oluşturduğunuz nesneye atanır. Onun tür anlamsız ..... ve sadece bir isim alanı ve bu nesneler üzerinde gerçek sahipliğini karıştırır. Bana sorarsanız kötü tasarımı .... kim tasarladıysa.

Yapmaları gereken şey "Gruplar" oluşturmak ve şemaları ve rolleri atmak ve sadece istediğiniz herhangi bir kombinasyondaki grup gruplarını sıralamanıza izin vermek, daha sonra her bir aşamada sisteme izinlerin miras alındığını, reddedildiğini veya üzerine özel olarak yazıldığını söyleyin olanlar. Bu çok daha sezgisel olurdu ve DBA'ların gerçek nesnelerin bu nesnelerde kim olduğunu daha iyi kontrol etmesine izin verecekti. Şu anda onun çoğu durumda ima dbo varsayılan SQL Server kullanıcı bu haklara sahip .... kullanıcı değil.

Uzun yıllar çalıştığım bir ORACLE mağazasında, farklı ön uç uygulamalarına uygulanan prosedürleri (ve paketleri) kapsüllemek için şemalar kullanıldı. Her uygulama için farklı bir 'API' şeması genellikle kullanım örnekleri, kullanıcılar ve sistem gereksinimleri oldukça farklı olduğundan mantıklıydı. Örneğin, bir 'API' şeması yalnızca geliştiriciler tarafından kullanılacak bir geliştirme / yapılandırma uygulaması içindi. Başka bir 'API' şeması, görünümler ve prosedürler (aramalar) yoluyla istemci verilerine erişmek içindi. Geliştirme / yapılandırma ve istemci verilerini kendi veritabanına sahip bir uygulama ile senkronize etmek için kullanılan başka bir 'API' şeması kapsüllenmiş kodu. Bu 'API' şemalarının bazıları, kapaklar altında, ortak prosedürleri ve işlevleri birbirleriyle paylaşmaya devam eder (diğer 'ORTAK' aracılığıyla)

Şemaya sahip olmamanın muhtemelen dünyanın sonu olmadığını söyleyeceğim, ancak çok yardımcı olabilir. Gerçekten, SQL Server'da gerçekten aklımda problemler yaratan paketlerin eksikliği ... ama bu farklı bir konu.

Şemalar yeni özellikler (SQL Server veya başka bir yazılım aracı olsun) gibi düşünüyorum. Geliştirme kitinize eklemenin faydasının tasarım ve uygulamadaki sadelik kaybını dengelediğini dikkatlice değerlendirmeniz gerekir.

Şemalar kabaca isteğe bağlı ad alanlarına eşdeğer gibi görünüyor. Nesne adlarının çarpıştığı bir durumdaysanız ve izinlerin ayrıntı düzeyi yeterince iyi değilse, işte size bir araç. (Öncelikle daha temel bir düzeyde ele alınması gereken tasarım sorunları olabileceğini söylemeye meyilli olurum.)

Sorun şu ki, eğer varsa, bazı geliştiriciler kısa süreli fayda için rasgele kullanmaya başlayacak; ve içeride bir kez kudzu olabilir.

SQL Server 2000'de, oluşturulan nesneler, bir kullanıcı Sam'in örneğin Çalışanlar gibi bir nesne oluşturduğunu söylüyorsa, söz konusu tabloya aşağıdaki gibi görünecektir: Sam.Employees. Sam compnay'den ayrılıyorsa veya diğer iş alanlarına taşınıyorsa ne olacak? Sam kullanıcısını sildiğiniz anda Sam.Employees tablosuna ne olur? Muhtemelen, öncelikle Sam.Employees'den dbo.Employess'e sahipliği değiştirmeniz gerekir. Şema bu sorunun üstesinden gelmek için bir çözüm sunar. Sam tüm nesnelerini Emp_Schema gibi bir şemada oluşturabilir. Şimdi, eğer Emp_Schema içinde bir nesne Çalışanlar oluşturursa, nesne Emp_Schema.Employees olarak adlandırılacaktır. Sam kullanıcı hesabının silinmesi gerekse bile, şema etkilenmez.

geliştirme - geliştiricilerimizin her biri oynamak için bir sanal alan olarak kendi şemasını alır.

Burada SQL Server ile şemaları kullanmak için iyi bir uygulama örneği. Birkaç ms-erişim uygulamamız vardı. Bunları bir ASP.NET Uygulama portalına dönüştürmek istedik. Her ms-access uygulaması o portal için bir Uygulama olarak yazılmıştır. Her ms-access uygulamasının kendi veritabanı tabloları vardır. Bunlardan bazıları ilişkilidir, bunları SQL Server'ın ortak dbo şemasına koyarız. Gerisi kendi şemalarını alır. Bu şekilde, ASP.NET uygulama portalındaki bir uygulamaya ait olan ve kolayca gezinilebilen, görselleştirilebilen ve bakımı yapılabilen tabloları bilmek istersek.