Veritabanı geliştirme için neden Visual Studio 2010'u SSMS üzerinden kullanmalıyım?

Visual Studio 2010, veritabanı projelerini ve sözde veritabanı geliştirmeyi kolaylaştıran bir dizi ilgili özelliği sunmaktadır. Veritabanı geliştirmemi sorunsuz bir şekilde yapmak için yıllardır SQL Server Management Studio'yu (SSMS) kullandım.

• SSMS benim için çalışırken neden VS2010 ile uğraşmalıyım? Özellikle, SSMS'den daha iyi ne yapar?
• Fakat belki de benim önerim yanlıştır ve SSMS hala veritabanı geliştirme için VS'yi aştı. Eğer öyleyse, bu hangi yönlerden doğrudur?

Aslında dürüst olmak gerekirse, biraz VS2010 ile beslendi. Ben eski bir okul tablo senaryo oluşturmak ve saklı yordamlar için dosyaları çalışmak daha kolay olduğunu düşünüyorum. Şema yönetimine ihtiyacınız varsa Redgate SQL Compare Pro'yu birkaç yüz dolara alabilirsiniz.

Bir veritabanı modelleme aracına gerçekten ihtiyacınız varsa, Powerdesigner ve hatta Erwin, özellikle ucuz olmasalar da, çok daha iyi bir iş çıkarır.

SSMS'yi tercih etsem de ikisini de kullandım. Bazı artılar ve eksiler:

• SSMS, SQL geliştirme için 'sadece işe yarayan' bir kullanıcı arayüzüne sahiptir. Sadece oluşturma komut dosyalarını oluşturmak ve kullanmak, VS2010'un sizi atlamak için kullandığı kasnaklardan çok daha uygundur. Çok, çok daha esnek (+ SSMS).

• VS2010, temel şema yönetimine sahiptir (yani fark / yama betiği oluşturma) (+ VS2010). Ancak o kadar iyi değil ve bazı kusurları var. Örneğin, ad üzerindeki kısıtlamalarla eşleşiyor. Bir sütunda adlandırmadan kontrol veya varsayılan kısıtlamalarınız varsa, SQL Server, sahne arkasında rasgele bir ad oluşturur. Kısıtlamaları farklı adlara sahip olabileceğinden, komut dosyasını farklı bir makineye yüklerseniz, bu VS2010'u karıştıracaktır. Redgate daha ucuz ve daha iyi. (+ VS2010, ancak hatalı).

• VS2010 gerçekten sakar - her tablo ya da diğer DB nesnesi için bir dosyaya ihtiyacınız var. Esasen, oldukça hantal olan VS2010 yolunu yapmanız gerekir. (- VS2010)

• VS2010 da biraz kırılgan ve kaynak kontrol entegrasyonu lapa lapa. Basit bir veritabanında bile her tablo, kısıtlama, saklı yordam, dizin ve diğer veritabanı nesnesi kendi dosyasıdır. Dosyalar her zaman projeye eklenir, (C # ile) tipik bir programlama projesinden çok daha hızlıdır. İyimser eşzamanlılık sayesinde, kayıtlar senkronize olmadıkça projeden dosyaları sessizce bırakma eğilimindedir. İyi takım disipliniyle bile, UI'den durum hakkında geri bildirim çok kötüdür. Bu karmaşık bir modelde bir felaket olurdu. (-VS2010 - Neredeyse büyük bir proje için gösteriyi durduran bir kusur olduğunu düşünürdüm).

• SSMS, SQL Server ile birlikte gelir - fiyatı (+ SSMS) yenemezsiniz.

• VS2010, hala (örneğin) PowerDesigner veya Oracle Designer gibi uygun bir depoya sahip değil. Veri modelini veritabanına kurmadan kolayca sorgulayamazsınız. (- VS2010).

Genel olarak, VS2010'u bir B- ile derecelendiririm. İki olgu tablosu ve yaklaşık 15 boyut ile nispeten basit bir veritabanı projesinde sakardı.

Şimdiye kadar yaptığım en büyük veri modeli, yaklaşık 560 tablodan oluşan bir dava davası yönetim sistemi içindi. VS2010'u bu boyutta bir proje için tavsiye etmem (bunu Oracle Designer'da yaptım). Temelde akıllı olmaya çalışıyor ve paradigma pek de işe yaramıyor. PowerDesigner gibi bir türün en iyisi modelleme aracıyla veya elle tablo oluşturma komut dosyası kullanarak daha iyisin.

SSMS basit ve güvenilirdir ancak manueldir. Modeli nasıl yönetmek istediğinize dair sınırsız kontrole sahipsiniz. Redgate SQL Compare gibi bir şema yöneticisi ve PowerDesigner gibi iyi bir modelleme aracıyla birleştirin ve VS2010'dan çok daha iyi bir pakete sahipsiniz.

Özet Başka projeler içeren VS çözümleriyle (belki de) entegrasyon dışında katil özellikler veya avantajlar önerebileceğimden emin değilim. Zaten VS2010 premium veya ultimate değerine sahipseniz, .Net takım zincirinizle birlikte attığınız hatalı bir veritabanı geliştirme aracı elde edersiniz. DB projelerini VS çözümünüze entegre edecek, böylece en azından sproc dağıtım komut dosyaları oluşturmak için kullanabilirsiniz.

Bununla birlikte, VS'in konuşacak bir modelleme aracı yoktur, bu nedenle PowerDesigner ve hatta Erwin bu konuda daha iyidir. Redgate'in şema yönetimi çok daha iyi ve SQL Compare Pro oldukça ucuz (yaklaşık £ 400 IIRC). IMHO SSMS, T-SQL geliştirme için çok daha iyi çalışır, ancak kesinlikle VS2010 ile yapabilirsiniz.

VS2010 primi, türünün en iyisi bir veritabanı modelleme aracından daha ucuz değildir ve VS2010 ultimate en az kadar pahalıdır. VS projeniz ile sıkı entegrasyon pahasına üçüncü parti araçlarıyla muhtemelen daha iyi yapabilirsiniz.

Bir alternatif

Sanırım en az bir alternatif önermeden ve artılarını ve eksilerini özetlemeden VS2010'u çok fazla cüruf etmemeliyim. Bunun için büyük bir proje üstleneceğim. Bugünlerde ağırlıklı olarak A / P işi yapmama rağmen, esas olarak çalıştığım 10 personel aralığında, veri modelini (ve bazı geliştirme çalışmalarını) yaptığım 100'den fazla personel yılı projesinde yer aldım. Bir analist veya geliştirici olarak. Çoğunlukla bugünlerde veri ambarı sistemleri üzerinde çalışıyorum, ancak daha büyük projeler temel olarak uygulamalardı. Çeşitli araçlar konusundaki deneyimlerime dayanarak, alternatif bir takım zinciri için bazı öneriler:

• VS2010 profesyonel veya daha yüksek. Premium veya nihai proje yönetimi özelliklerini kullanmak isteyebilirsiniz veya istemeyebilirsiniz.
• Subversion, AnkhSVN ve TortoiseSVN - Her gün TFS'den daha iyi ve VS ile iyi oynar. Aynı zamanda, eş zamanlı geliştirme iş akışları için yerel depolarda tarım yapmak oldukça uygundur.
• T-SQL geliştirme için SSMS - Proje yönetimi ve SC entegrasyonu o kadar iyi değil ama DB geliştirme çalışmaları için iyi çalışıyor.
• Sproc dosyalarını izlemek için VS2010 DB projesi - SSMS kullanıyorsanız ancak çalışıyorsa biraz sakar. Ayrıca dağıtım komut dosyaları da üretecektir.
• PowerDesigner - Bir veritabanını modellemede ve DB şema öğelerini yönetmede daha iyi bir yol. Ayrıca, MDA'ya yoğun bir şekilde girmek istiyorsanız, UML de yapar. DB tasarımınızı bir nesne modelinden çıkarmak istiyorsanız bunun yerine Sparx EA'yi düşünebilirsiniz. Veri tabanı modellemesi istenen bir şey bıraksa da, gördüğüm herhangi bir CASE aracının en iyi Meta CASE (genişletilebilir meta modeli) işini yapıyor.
• SQL Compare pro - DB yama komut dosyaları oluşturmak veya manuel yama komut dosyalarını test etmek için bunu kullanın (aşağıdaki 1'e bakın).
• Framemaker - Eğer bir özellik üzerinde çalışan birden fazla analist varsa, Word'den çok daha kararlı ve daha iyi grup yazılımı özellikleri. Ayrıca koşullu dahil edilmeyi de destekler, böylece gizlenmiş WIP değişikliklerine sahip bir spekülasyon sürümlerini sürümlere alabilirsiniz. MIF ve MML, API belgelerini ve veri sözlüklerini özellik belgelerine entegre etmeyi oldukça kolaylaştırır. Bunu yapmanız, spesifikasyonda onlara çapraz referans verebileceğinizden oldukça faydalıdır. Metinsel etiket çapaları, çapraz referansları yeniden içe aktarma işlemlerinde sabit tutar. TCS'yi, belgeyi PDF, HTML ve CHM çıktısına tek kaynak olarak da kullanabilirsiniz.
• Açık kaynak kodlu yayın izleyici - Çok sayıda açık kaynak kodlu yayın var (örneğin, kullandığım bir çiftin adını TRAC, Bugzilla) Açık kaynaklı olanları değiştirmek veya özel bir iş akışına entegre etmek daha kolaydır ve fiyatı geçemezsiniz.
• NUnit veya diğer test araçları - otomatikleştirilmiş test araçları gereksinimlerinize en uygun olanı.
• MS projesi dışında her şey - Zararlı olarak kabul edildi. MS projesi çok içe bakmaktadır ve proje planlarını, paydaşlara veya diğer üçüncü taraflara belirsizliği, riski veya bağımlılıkları etkin bir şekilde temsil etmeyen bir modele zorlamaktadır (aşağıdaki 2'ye bakınız).

Artıları: VS2010'dan daha iyi veritabanı modelleme ve şema yönetimi, daha iyi sürüm kontrol sistemi, yapı ve proje iş akışını özelleştirmek daha kolay, teknik özelliklerin ve belgelerin daha iyi yönetimi.

Eksileri: Araçları birleştirmek için daha fazla çaba, oluşturma sürecine sınırlı DB entegrasyonu.

Varsayımlar: Değişim / bırakma sürecinin kontrolünün DB şemaları için otomatik veya sıkı bir şekilde entegre bırakma yönetiminden daha önemli olduğunu varsayar. Ayrıca, otomatikleştirilmiş DB şema yönetiminin% 100 güvenilir olmadığını varsayar.

Çok yüksek teknolojiye sahip değil ya da kayıtsızca entegre değil, karmaşık bir proje için muhtemelen sevimli otomatik özelliklerden daha fazla kontrole ilgi duyuyorsunuz. En iyi cins araçlarıyla daha iyi durumda olduğunuzu ve ne tür bir ev demeti oluşturduğunu ve kod yazmayı gerekli kılacağınızı savunuyorum. Yapınızı (a) anlamak oldukça basit ve (b) tamamen otomatik tutmaya çalışın.

1. DB yamaları üzerinde KG. Büyük bir şemada, özellikle yamalar veri geçişini içeriyorsa, canlı sistemler için manuel bir yama işlemine sahip olmak isteyebilirsiniz. Örneğin, gerekirse bir değişikliğin desteklenmesini desteklemek için geri sarma ve geri sarma komut dosyalarının olması istenebilir. Bu durumda, yamanın gerçekte düzgün çalıştığını test etmek için bir tesise sahip olmak isteyeceksiniz. Bir veritabanında veritabanı şemasını yönetiyorsanız, komut dosyalarını veritabanlarından önce ayarlayarak ve depodan bir referans veritabanı oluşturarak komut dosyalarını test edebilirsiniz. Yama betiğini önceki veritabanında çalıştırmak, repositiry modeliyle senkronize etmelidir. Bunu test etmek için bir şema karşılaştırma aracı kullanılabilir.

2. Son zamanlarda ısmarlama uygulama geliştirmeden çok daha fazla veri ambarı ve entegrasyon çalışması yaptım, bu nedenle çoğu zaman bir geliştirme ekibinden daha sık karşılaşıyorum. Bununla birlikte, proje yönetimi araçları ve metodolojileri dış paydaşları yönetmek için çok zayıf bir iş yapmaktadır. Veri ambarı gibi bir entegrasyon projesinde, program yönetimi karşısında dışsal bağımlılıkları (yani kontrol etmediğim) gerçekten zorlayan bir proje yönetim aracı görmek istiyorum. Önemsiz olan herhangi bir entegrasyon projesinde, dışsal bağımlılıklar, harcanan zamanın en büyük itici güçleri.

İlk başta gönderildiğinden beri bu sorunun cevabını nasıl yapılandıracağım. VS2010 için durum, aletin özelliklerini ve faydalarını tanımlamakla ilgili olmadığı için zor. Bu, okuyucuyu veri tabanı geliştirme yaklaşımlarında temel bir değişiklik yapmaya ikna etmekle ilgilidir. Kolay değil.

Bu sorunun cevabını DBA, geliştirici / dba ve hem OLTP hem de veri depolamayı kapsayan bir arka plan karması ile tecrübeli veritabanı uzmanlarından yanıtlar bulabilirsiniz. Tek bir oturumda veri tabanı geliştirme sürecinin her yönü için buna yaklaşmam uygun değil, bu yüzden belirli bir senaryo için dava açacağım.

Projeniz bu kriterlere uyuyorsa, VS2010 için zorlayıcı bir durum olduğunu düşünüyorum:

• Ekibiniz uygulama geliştirme için VS2010 kullanıyor.
• Ekibiniz kaynak kontrolü ve derleme yönetimi için TFS kullanıyor.
• Veritabanınız SQL Server.
• Ekibiniz, VS otomatikleştirilmiş testine zaten sahip veya ilgileniyor.

Eğer veritabanı geliştirme için VS2010 değerlendiren yapıyorsanız, İncil olacak Visual Studio Veritabanı Kılavuzu gelen Visual Studio ALM Rangers . Referansları olmayan takip eden alıntılar bu belgeden olacaktır.

Git o zaman ...

Veritabanı geliştirme süreci uygulama geliştirmeden neden farklı?

Veri. Bu sinir bozucu veriler için olmasaydı, veritabanı geliştirme bir çifte olurdu. Her sürümde her şeyi DROP yapabilir ve bu sıkıntılı değişim yönetimini unutabiliriz.

Verilerin varlığı, veri tabanı tablolarını veya diğer veri şemalarının şeklini etkileyen uygulama geliştirme çabaları tarafından değişiklikler yapıldığında veri taşındığı, dönüştürüldüğü veya yeniden yüklendiği için veri tabanı değişim sürecini zorlaştırmaktadır. Bu değişim süreci boyunca, üretim kalitesi verileri ve operasyonel durum, kurumun bütünlüğünü, değerini ve kullanışlılığını tehlikeye atabilecek değişikliklere karşı korunmalıdır.

SSMS'nin nesi var?

Buna bir sebep olarak SQL Server Management Studio deniyor. Bağımsız bir araç olarak, geliştirme çabalarını yönetmek için pratik değildir eğer Kabul en iyi uygulamaları takip edeceğiz.

Yalnızca komut dosyaları ile, geliştirilmeniz için oluşturulan kaynak kontrol uygulamalarını anlamlı bir şekilde uygulamak için, her iki nesne tanımını da (örneğin bir CREATE TABLE komut dosyası) korumalı ve komut dosyalarını değiştirmelisiniz (örneğin ALTER TABLE) VE senkronize kaldıklarından emin olmak için çok çalışmalısınız.

Bir tablodaki değişikliklerin sürümleri zinciri oldukça hızlı bir şekilde karıştırılabilir. Çok basit bir örnek:

-- Version 1
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20))

-- Version 2
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(50))

-- Version 3
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(100))

Sürüm 3'e göre, veritabanı değişiklik komut dosyası şunları içerir:

ALTER TABLE dbo.Widget ADD Description VARCHAR(50)
ALTER TABLE dbo.Widget ALTER COLUMN Description VARCHAR(100)

Bu veritabanının canlı sürümü sürüm 1 ise ve bir sonraki sürümümüz sürüm 3 ise, aşağıdaki komut tüm gerekli olacaktı ancak bunun yerine her iki ALTER ifadesi çalıştırılacak.

ALTER TABLE dbo.Widget ADD Description VARCHAR(100)

5 yıllık 4 haftalık sprintler bazı eğlenceli versiyon senaryoları ekler ve dağıtım süresi üzerindeki etkiyi en aza indirmek için ek insan kullanımı gerektirir.

Peki SSMS ile ilgili bir sorun mu var? Hayır, SQL Server'ı yönetmek, yönetmek ve yönetmek için iyi bir şeydir. Yaptığı gibi davranmadığı şey, bir veritabanı geliştiricisine (zaman zaman) değişimi yönetme görevini yerine getirmekte yardımcı olmaktır.

Veritabanının her sürümünü kaynaktan kuramaz ve gelecekteki sürümlere yükseltemezseniz, kaynak kontrolünüz bozulur. Eğer öyle düşünmüyorsan, Eric Sink’e sor .

Peki ya SSMS + <- şema karşılaştırma aracını ekle ->?

Bu kesinlikle doğru yönde bir adımdır ve senaryoları korumak için gereken manuel çabanın çoğunu elinden alır. Ancak (ve bu büyük bir şeydir), genellikle ilgili manuel adımlar vardır.

Popüler şema karşılaştırma araçları tamamen otomatik olabilir ve yapım sürecine entegre edilebilir. Ancak, benim deneyimlerime göre, en yaygın uygulama elle yapılan bir karşılaştırma için, ortaya çıkan betikler göz küresine alınmış, kaynak kontrolünde kontrol edilmiş, sonra dağıtmak için manuel olarak çalıştırılmıştır. İyi değil.

Ne zaman yanılabilir insanları inşa etme ya da yerleştirme sürecine dahil etmek zorunda kalırsak, riski ortaya çıkarır ve süreci tekrarlanamaz hale getiririz.

Siz ve ekibiniz tamamen otomatik şema karşılaştırması ve dağıtımı olan birkaç kişi arasındaysanız, size şapka atmak! Sizler VS2010'un sunduğu avantajlara açık olma ihtimaliniz çok yüksektir:

• Manuel adımların tehlikeli olduğunu zaten kabul ettin.
• Otomasyonun değerini görüyorsunuz.
• Çalışması için gereken zamana yatırım yapmaya hazırsınız.

Tek bir adımda bir derleme oluşturamazsanız veya tek bir adımda konuşlandırmazsanız, geliştirme ve dağıtım işleminiz bozulur. Eğer öyle düşünmüyorsan, Joel Spolsky'ye sor .

Neden VS2010?

Sorulan @NickChammas sorusu, VS2010'un neden veritabanı geliştirme için bir oyun değiştirici olduğunu gösteren katil özellikler arıyor. Bu temele dayanabileceğimi sanmıyorum.

Belki de komik olarak, başkalarının bu araçta kusur gördüğü yerlerde benimsemenin güçlü nedenlerini görüyorum:

• Yaklaşımınızı değiştirmek zorunda kalacaksınız.
• Siz ve ekibiniz farklı bir şekilde çalışmak zorunda kalacaksınız.
• Her değişikliğin etkisini, ayrıntılı olarak değerlendirmek zorunda kalacaksınız.
• Her değişikliğin önemsiz hale getirilmesine yönlendirileceksiniz .

Bir projedeki tek DBA'sınız, veritabanındaki tüm değişiklikleri yönetiyorsanız, bu mantık saçma üzerinde saçma bir kenarlık gibi görünmelidir. Bununla birlikte, @BrentOzar'ın bir noktaya sahip olduğunu düşünüyorsanız ve yeni kurallardan biri, Herkesin DBA'sı olduğunu düşünüyorsa , veritabanı değişimini ekipteki her geliştiricinin çalışabileceği şekilde kontrol etmeniz gerekecektir.

Veritabanı Projelerinin Kabulü, bazı geliştiriciler için zihinsel bir değişim ( eski alışkanlıkların kırılması zordur ) veya en azından süreç veya iş akışlarında değişiklik gerektirebilir. Üretim veritabanının veritabanının geçerli sürümünü temsil ettiği veritabanı uygulamaları geliştiren geliştiricilerin , kaynak kodun veritabanlarında değişiklik yapılan araç olduğu kaynak koduna dayalı bir yaklaşım benimsemesi gerekecektir . Visual Studio Veritabanı Projelerinde, proje ve kaynak kodu, veritabanı şeması için "Gerçeğin Bir Sürümü" dür ve geliştirici veya kuruluş tarafından uygulama yığınlarının diğer bölümleri için zaten kullanılmış olan SCM iş akışları kullanılarak yönetilir. Veriler için, üretim veritabanı olması gerektiği gibi “Gerçeğin Bir Versiyonu” olarak kalır.

VS2010'un veritabanı geliştirme yaklaşımını başarılı bir şekilde benimsemek için gerekli olan temel değişime ulaştık ...

Veritabanınızı kod olarak kabul edin

Artık canlı veritabanını değiştirmek yok. Her veritabanı değişikliği, bir uygulama değişikliği ile aynı kalıbı izleyecektir. Kaynağı değiştirin, derleyin, dağıtın. Bu Microsoft'tan geçici bir yön değişikliği değil, bu SQL Server'ın geleceğidir . Kod olarak veritabanı kalmak için burada.

Veritabanı geliştiricisi, uygulamanın sürümü için nesnenin şeklini tanımlar, veritabanı motorundaki mevcut nesnenin istenen şekle nasıl dönüştürüleceğini değil. Kendinize soruyor olabilirsiniz: Bu zaten müşteri tablosunu içeren bir veritabanına nasıl dağıtılır? Dağıtım motorunun çalmaya başladığı yer burası. Daha önce belirtildiği gibi, dağıtım motoru, şemanızın derlenmiş sürümünü alır ve bir veritabanı dağıtım hedefi ile karşılaştırır. Farklılaştırıcı motor, projeden dağıtmakta olduğunuz sürümle eşleşmesi için hedef şemayı güncellemek için gerekli komut dosyalarını üretecektir.

Evet, benzer bir modeli izleyen başka araçlar da var ve cevabımdaki sınırlamalar dışında kalan projeler için, aynı derecede dikkate değer. Ancak, Visual Studio ve Team Foundation Server ALM ile çalışıyorsanız, rekabet edebileceklerini sanmıyorum.

VS2010 veritabanı projelerinde yanlış olan nedir?

• Mükemmel değiller . Ancak sınırlamaların ve sorunlu alanların farkındaysanız, bunları geçici olarak çözebilirsiniz.
• Karmaşık veri hareketleri hala dikkat ve dikkat gerektiriyor ancak dağıtım öncesi / sonrası komut dosyaları için hazırlanmıştır.

Düzenleme: Peki o zaman amacın ne?

@AndrewBickerton, orijinal soruyu cevaplamadığım bir yorumdan bahsetti, bu yüzden şunu özetleyeceğim: "Neden veritabanı geliştirme için SSMS üzerinden Visual Studio 2010 kullanmalıyım?" İşte.

• SSMS bir veritabanı geliştirme aracı değildir. Evet, SSMS ile TSQL geliştirebilirsiniz, ancak VS2010'un zengin IDE özelliklerini sağlamaz.
• VS2010 veritabanınızı kod olarak ele almak için bir çerçeve sağlar.
• VS2010, statik kod analizini veritabanı kodunuza getirir .
• VS2010, yap-konuş-test döngüsünü tamamen otomatikleştirmek için araçlar sunar.
• SQL2012 ve Visual Studio vNext, veritabanı projelerinin yeteneklerini genişletiyor. Şimdi VS2010 ile tanışın; yeni nesil veritabanı geliştirme araçlarına başlayabilirsiniz.

SSMS'yi bilmiyorsanız veya 3. taraf araçlarını kullandıysanız VS harika görünebilir. Şema karşılaştırması vs. için Red Gate araçları kullanıyorsanız VS'deki boşluklar göze çarpıyor. Ayrıca ücretsiz SSMS eklentileri de var.

Kaynak kontrol bitleri yanıltıcıdır: Üretim veritabanında olan referans referansınızdır. Geliştiricinin kullandığı şey değil. Görmek

• https://stackoverflow.com/q/1597085/27535
• https://stackoverflow.com/q/4433153/27535

SSRS rapor tasarımı ve SSIS paketleri için Visual Studio'yu yoğun şekilde kullanıyorum (yani, BIDS). Management Studio'da hiç de iyi yapamadım. Visual Studio çok daha eksiksiz ve entegre bir geliştirme ortamıdır ve Kaynak Kontrol sistemlerine de çok daha iyi bir şekilde bağlıdır. Ve hepsi bu fiyata yansıdı!

Dürüst olmak gerekirse, oyum veritabanı tasarımı, geliştirilmesi ve (açıkçası) yönetim için doğrudan SQL Server Management Studio'ya gidiyor. Yazması daha kolay:

create table newTable
(
    someId int identity(1, 1) not null primary key clustered,
    ...... you get the idea
)

Sonra doğru yerlere tıklayın. SSMS harika bir düzen ve çalışmak için kesinlikle bir fırsat. Ve doğası gereği bir .NET yazılım geliştiricisiyim. Fakat veritabanı tasarımı ve kodlaması söz konusu olduğunda, SSMS'yi 10 üzerinden 11 kez seçeceğim.

En iyi uygulama yoktur, ancak VS 2010 veritabanı projesi ve kaynak kodu denetleyicisi (VSS 2010, Subversion vb.) İle veritabanınızı sürümlendirebilirsiniz.

İlk önce veritabanınızı doğrudan SSMS'ye tasarlamanızı öneririm. Veritabanınız neredeyse hazır olduktan sonra, VS 2010 veritabanı projesine aktarın. İçe aktarma işlemi tamamlandıktan sonra, tüm değişiklikleri takip etmek için her zaman veritabanı projenize yeni komut dosyaları eklemelisiniz. Geliştirme sunucusundaki tüm değişiklikleri almak ve tüm bu komut dosyalarını doğrudan projenize içe aktarmak için veritabanı projesinin karşılaştırma özelliğini kullanabilirsiniz. Artık değişikliklerinizi kaynak kod denetleyicinize "adamak" zorundasınız.

Bu yöntemle, sürümlü bir veritabanına sahip olabilirsiniz. Her değişikliğin sürümünü görebilir ve değişikliklerinizi geri alabilirsiniz.

Bu tek avantaj değil. Bu tür bir projeyle, değişiklikleri kodlamak için herhangi bir veritabanını projenizle karşılaştırabilir ve SQL PowerShell komut istemiyle tüm veritabanlarınızı aynı komut dosyasıyla güncelleyebilirsiniz: bu komut dosyası veritabanınızın XML şemasıdır. Veritabanlarınızı güncellemek için yalnızca gerekli komutları çalıştıracaktır. Ayrıca veritabanınızdaki birim testini yapma olanağınız da vardır . Veri tabanı projesi için başka iyi bir makale burada bulabilirsiniz . Dağıtım özelliği ile, komut dosyası öncesi ve komut dosyası sonrası olabilir. Bu komut dosyaları ile doğrulama yapabilir veya sistem tablolarınıza veri giremezsiniz.

İşte veritabanı projesi için adım adım prosedür.

SSMS'yi VS2010'dan daha çok kullanıyorum çünkü SQL Server'ı kurduğumda orada. Muhtemelen SSMS'nin VS2010, IMHO'dan daha çok kullanılmasının en önemli nedeni budur.

Ayrıca, Red-Gate gibi üreticilerin, SSMS ile bütünleşen ve mutlaka VS2010 ile uyumlu olmayan aletler ortaya koyduğunu gördüm. Bu, Microsoft'un sahip olmadığı SSMS'yi geliştirmenize olanak sağlaması bakımından olumlu olabilir. Bunun bir örneği, SSMS'ye, SSMS'yi Visual Team Foundation ya da neye sahip olduğunuza bağlı olarak şirketinizin Kaynak Kontrol sistemine bağlamanıza izin veren bir eklenti olan Red-Gate'in SQL Kaynak Kontrolüdür. VS2010 bu dahili sisteme sahip ancak Reg-Gate'in aletinin fiyatı ile karşılaştırıldığında, VS2010'u satın almak zorunda kalmadan bir demet para biriktirdim.

Bence genel tercihlere bağlı, rahat olduğunuz şeyle çalışıyorsunuz. Yeni bir kişiyi eğitiyorsanız ve onları VS2010'da eğitiyorsanız, bu onların tercihi olacak çünkü bununla nasıl başa çıkacaklarını biliyorlar.

SQL Server 2012 ile oynamaya başladıysanız, SSMS'nin VS2010'un makyajını yavaş ama emin bir şekilde aldığını fark etmiş olabilirsiniz. Sonuçta, aralarındaki farkı söyleyemeyebilirsiniz.