İçerdiği veritabanlarının dezavantajları var mı?

SQL Server 2012, veritabanında ihtiyaç duyulan her şeyin (iyi, çoğunlukla her şeyin) veritabanının içinde bulunduğu "içerdiği" veritabanları kavramını ortaya koydu. Bu, veritabanları sunucular arasında taşınırken büyük avantajlar sunar. Yeni bir veritabanı tasarlarken bu benim varsayılan stratejim olmalı, o zaman bilmek istiyorum.

MSDN, içerilen veritabanları için çeşitli dezavantajları listeler ve büyük olanları değişiklik izleme ve çoğaltma için destek eksikliğidir. Diğerleri var mı Bu özellikleri kullanmayacaksam, içerilen veritabanlarını kullanmamak için herhangi bir neden var mı?

İçerdiği veritabanlarının temel amacı, etrafındaki çok fazla iskele kurmadan veritabanınızı yeni bir sunucuya taşımayı kolaylaştırmaktır. Bunu göz önünde bulundurarak, bu geçişi zorlaştıracak birkaç olası sorunu ele alacağım - ve çoğu, içerilen veritabanlarının sadece kısmen SQL Server 2012'de barındırılması (çevreleme zorunlu değildir) etrafında dönüyor.

Bağlantı dizeleri

Bir içeriyordu veritabanına bağlantı dizeleri gerekir bağlantı dizesinde açıkça veritabanı belirtin. Bir bağlantı kurmak için artık oturum açmanın varsayılan veritabanına güvenemezsiniz; bir veritabanı belirtmezseniz, SQL Server içerdiği tüm veritabanlarını adım adım izlemeyecek ve kimlik bilgilerinizin uyuşabileceği herhangi bir veritabanı bulmaya çalışmayacaktır.

Cross-db sorguları

Aynı kullanıcıyı aynı sunucuda bulunan iki farklı veritabanında aynı parola ile oluştursanız bile, uygulamanız veritabanı arası sorgulama yapamaz. Kullanıcı adları ve şifreler aynı olabilir, ancak aynı kullanıcı değildirler . Bunun nedeni? Barındırılan bir sunucuda veritabanları içeriyorsanız, aynı barındırılan sunucuyu kullanan başkasıyla aynı kullanıcıyı kullanması engellenmemelidir. Tam kapsama olasılıkla (geldiğinde SQL Server 2012'den sonra sürümünde asla), veritabanı çapraz sorguları yine de kesinlikle yasaktır. Son derece, çok, kesinlikle içerdiği veritabanı kullanıcıları ile aynı adda sunucu düzeyinde girişler oluşturmamanızı ve içerilen veritabanları arasında aynı içerilen kullanıcı adını oluşturmaktan kaçınmaya çalışmanızı öneririm. Birden çok içerilen veritabanına çarpan sorguları çalıştırmanız gerekirse, uygun ayrıcalıklara sahip bir sunucu düzeyinde giriş yapın (bunun olduğunu düşünebilirsiniz sysadmin, ancak salt okunur sorgular için, bu CONNECT ANY DATABASEve SELECT ALL USER SECURABLES).

Eş anlamlı

Çoğu 3- ve 4 parçalı adın tanımlanması kolaydır ve bir DMV'de görünür. Ancak, 3- veya 4 parçalı bir adı işaret eden bir eşanlamlı oluşturursanız, bunlar DMV'de görünmez. Bu nedenle, eş anlamlı terimlerden yararlanırsanız, bazı dış bağımlılıkları kaçırmanız mümkündür ve bu, veritabanını farklı bir sunucuya geçirdiğiniz noktada sorunlara neden olabilir. Bu konuda şikayette bulundum, ancak "tasarım tarafından" olarak kapatılmıştı ve yeni geri bildirim sistemine geçişi sürdüremedi . DMV'nin dinamik SQL ile oluşturulan 3- ve 4 parçalı isimleri de özleyeceğini unutmayın.

Şifre politikası

Parola ilkesi bulunmayan bir sistemde içerdiği bir veritabanı kullanıcısı oluşturduysanız, aynı kullanıcıyı, parola ilkesi olan farklı bir sistemde oluşturmayı zor bulabilirsiniz. Bunun nedeni, CREATE USERsözdiziminin parola ilkesini atlayarak desteklememesidir. Bu sorun hakkında bir hata yaptım ve açık kalmaya devam etti (ve Connect emekli olunca bu hamleye dayanamadı). Ve bana bir şifre politikası uygulanmış bir sistemde, politikayı kolayca atlayan sunucu düzeyinde bir giriş oluşturabileceğiniz, ancak bunu yapan bir veritabanı kullanıcısı yaratamayacağınız için garip görünüyor. güvenlik riski az.

karşılaştırma

Artık tempdb'nin harmanlamasına güvenemeyeceğimiz için, şu anda açık harmanlama kullanan veya bunun yerine DATABASE_DEFAULTkullanmak için herhangi bir kodu değiştirmeniz gerekebilir CATALOG_DEFAULT. Bazı olası sorunlar için bu BOL makalesine bakın .

IntelliSense

Bir içerilen veritabanına içerilen bir kullanıcı olarak bağlanırsanız, SSMS IntelliSense’i tam olarak desteklemeyecektir. Sözdizimi hataları için temel vurguyu elde edersiniz, ancak otomatik tamamlama listeleri veya araç ipuçları ve tüm eğlenceli şeyler yoktur. Bu konuda bir hata yaptım ve açık kalmaya devam etti - ve bir tanesi daha hamleye dayanamadı.

SQL Server Veri Araçları

SSDT'yi veritabanı geliştirme için kullanmayı planlıyorsanız, şu anda içerilen veritabanları için tam destek yoktur. Gerçekten de, SSDT şu anda ne içeriğin ne olduğunu ve onu neyin kırabileceğini bilmediği için, projeyi bozmanın bir engel ya da sözdizimi kullanırsanız başarısız olacağı anlamına geliyor.

ALTER VERİTABANI

Bir çalıştırırken ALTER DATABASEbir alan veritabanının kapsamında gelen komutu, rRather daha ALTER DATABASE fookullanmak gerekecektir ALTER DATABASE CURRENT- bu veritabanı hareket edilirse, vb değiştirildi bu komutlar, dış bağlam veya referans hakkında hiçbir şey bilmek gerekmez öyle mi .

Birkaç diğerleri

Muhtemelen hala kullanmamanız gereken, ancak yine de, desteklenmeyen veya kullanımdan kaldırılan ve içerilen veritabanlarında kullanılmaması gerekenler listesinde belirtilmesi gerekenler:

• numaralı prosedürler
• geçici prosedürler
• ilişkili nesnelerde harmanlama değişiklikleri
• veri yakalamayı değiştir
• izlemeyi değiştir
• kopya

Bunların hepsinin, içerilen veritabanlarını kullanmanın dezavantajları olması gerekmediği , sadece bilmeniz gereken konular olduğu ve bunların tümü resmi belgelerde açıkça açıklanmadığı belirtiliyor.

Ayrıca, içerilen bir veritabanının taşınacağından veya bir kullanılabilirlik grubunun bir parçası olduğundan veya yansıtıldığından emin olmanız gerekir, tüm potansiyel hedef sunucuların 1 olarak ayarlanmış sp_configureseçeneğine sahip olduğundan emin olun contained database authentication.

Sen bulabilirsiniz bu blog yazısı kullanışlı, hem de bu bir onlar RTM-tarih öncesi rağmen.

İçerdiği veritabanları hakkında daha fazla bilgi edinmek isteyenler için, bu makaleyi okumalarını önerebilirim http://www.sqlshack.com/contained-databases-in-sql-server/

Makale, içerilen veritabanlarının kullanılmasının ana avantajlarını / dezavantajlarını belirlemektedir.

Dezavantajları

Kısmen içerilen veritabanları, çoğaltma, veri yakalamayı değiştirme, izlemeyi değiştirme, harmanlama değişiklikleriyle yerleşik işlevlere bağlı olan şemaya bağlı nesneleri kullanamaz.

Avantajları

Öte yandan, daha önce de belirtildiği gibi, içerilen DB'leri kullanmanın bazı faydaları vardır:

• 
  Artık kullanıcı sorunları olmayacağından veritabanını bir sunucudan diğerine taşımak oldukça kolaydır.
• Meta veriler içerdiği veritabanlarında depolanır, böylece daha kolay ve daha taşınabilir
• İçerilen DB kullanıcıları için hem SQL Server hem de Windows kimlik doğrulaması yapmak mümkündür.

Makale ayrıca yardımcı olur:

• yeni bir içerilen veritabanı oluşturma (SQL Server'daki Seçenekler sayfasında Kısmi olarak bir sınırlama türü yaparak ve daha sonra bir veritabanı oluşturmak için T-SQL sorgusunu kullanarak)
• SQL Server Management Studio'yu kullanarak içerdiği DB'ye bağlanma (bağlantı parametresindeki içerilen DB adını belirtmeniz gerekir)
• varolan veritabanını içerilen veritabanına dönüştürme
• bir veritabanında çalışmak ve içerdiği kullanıcı türündeki tüm girişleri listelemek

Dezavantajı, içerdiği bir veritabanı kullanıcısının, giriş yapabildiği gibi kendi şifresini değiştirmeye zorlanamamasıdır (MUST_CHANGE ) . Kullanıcılara, değiştiren kullanıcı izni vermedikçe ve bir SQL ifadesi kullanarak nasıl değiştireceklerini söylemedikçe, kendi şifrelerini yönetemezsiniz. Kullanıcı arayüzleri üzerinden yönetebilecekleri hiçbir yer yoktur veya en azından nasıl yapacağımı bilmiyorum.

Ek not beklenmedik ve belgelenmemiş meta veri kullanımını "sadece" katalogunda olması gerektiğini düşündüğüm "PIVOT" VE "UNPIVOT" cümlesinde buldum (sys.tables / sys.columns / etc). Msdn'de belgelendiği gibi :

İçerdiği veritabanında, katalog harmanlaması Latin1_General_100_CI_AS_WS_KS_SC . Bu harmanlama, tüm SQL Server örneklerinde bulunan tüm veritabanları için aynıdır ve değiştirilemez.

Ancak "PIVOT" VE "UNPIVOT" yan tümcesinin aynı zamanda sistem kataloglarını bir yürütme mekanizması olarak kullandıklarından bahsetmediler. bu nedenle, göç sırasında "PIVOT" VE "UNPIVOT" yan tümcesinin kullanımına yakın her yerde bir çakışma çakışması hatası üretti. İşte bazı repro:

/*step1 create a table belongs to a contained database and populate some data*/
create  table dbo.test1 (col1 varchar(100),col2 varchar(100))
insert  dbo.test1 values('a','x')
insert  dbo.test1 values('b','y')
insert  dbo.test1 values('c','z')

/*step2 lets see its collation you will see it is correctly as same as its (contained) database */
select name,collation_name from sys.columns where object_name(object_id) = 'test1'

/*step3 reproduce an unpivoted column*/
select * into dbo.test2
from (select * from dbo.test1) a unpivot (val for col in (col1,col2)) a


/*step4 lets check its collation you will see the column specified at "FOR" clause is created as Latin1_General_100_CI_AS_KS_WS_SC */
select name,collation_name from sys.columns where object_name(object_id) = 'test2'

/*step5 make use of the unpivoted table without awareness will cause an error*/
select val + ' = ' + col from dbo.test2 

/*step6 clean up*/
drop table dbo.test1
drop table dbo.test2

Ayrıca, içerilen veritabanı hakkındaki makalelerin çoğunlukla eksik olduğunu da görebilirsiniz. bu yüzden onu kullanmaya karar vermek çok iyi bir doğaçlama gerektiriyor.