Tại sao tôi nên sử dụng Visual Studio 2010 qua SSMS để phát triển cơ sở dữ liệu của mình?

Visual Studio 2010 giới thiệu các dự án cơ sở dữ liệu và một loạt các tính năng liên quan được cho là tạo điều kiện phát triển cơ sở dữ liệu. Tôi đã sử dụng SQL Server Management Studio (SSMS) trong nhiều năm để thực hiện phát triển cơ sở dữ liệu của mình mà không gặp sự cố.

• Tại sao tôi phải bận tâm với VS2010 khi SSMS hoạt động với tôi? Điều gì, cụ thể, nó làm tốt hơn SSMS?
• Nhưng có lẽ tiền đề của tôi là không chính xác và SSMS vẫn vượt qua VS để phát triển cơ sở dữ liệu. Nếu vậy, theo những cách cụ thể nào là đúng?

Thật ra tôi đã hơi choáng ngợp với VS2010, thành thật mà nói. Tôi nghĩ rằng một tập lệnh tạo bảng cũ và các tệp cho các thủ tục được lưu trữ sẽ dễ làm việc hơn. Nếu bạn cần quản lý lược đồ thì bạn có thể nhận Redgate SQL So sánh Pro với giá vài trăm đô la.

Nếu bạn thực sự cần một công cụ mô hình hóa cơ sở dữ liệu thì Powerdesigner hoặc thậm chí Erwin thực hiện công việc tốt hơn nhiều, mặc dù chúng không đặc biệt rẻ.

Mặc dù tôi thích SSMS hơn, tôi đã sử dụng cả hai. Một số ưu và nhược điểm:

• SSMS có giao diện người dùng 'chỉ hoạt động tốt' để phát triển SQL. Chỉ cần xây dựng và sử dụng các tập lệnh tạo sẽ thuận tiện hơn nhiều so với các vòng lặp VS2010 buộc bạn phải nhảy qua. Nhiều, linh hoạt hơn nhiều (+ SSMS).

• VS2010 có quản lý lược đồ cơ bản (nghĩa là tạo tập lệnh khác biệt / vá lỗi) (+ VS2010). Tuy nhiên nó không tốt lắm và có một số sai sót. Ví dụ, nó phù hợp với các ràng buộc về tên. Nếu bạn có các ràng buộc kiểm tra hoặc mặc định trên một cột mà không đặt tên chúng, SQL Server sẽ tạo một tên ngẫu nhiên đằng sau hậu trường. Điều này sẽ gây nhầm lẫn cho VS2010 nếu bạn cài đặt tập lệnh trên một máy khác vì các ràng buộc có thể có các tên khác nhau. Redgate rẻ hơn và tốt hơn. (+ VS2010, nhưng thiếu sót).

• VS2010 thực sự vụng về - bạn cần có một tệp cho mỗi bảng hoặc đối tượng DB khác. Về cơ bản, bạn phải làm mọi thứ theo cách của VS2010, điều này khá cồng kềnh. (- VS2010)

• VS2010 cũng hơi mong manh và tích hợp kiểm soát nguồn không ổn định. Ngay cả trên một cơ sở dữ liệu đơn giản, mỗi bảng, ràng buộc, thủ tục được lưu trữ, chỉ mục và đối tượng cơ sở dữ liệu khác là tệp riêng của nó. Các tệp được thêm vào dự án mọi lúc, nhanh hơn nhiều so với một dự án lập trình thông thường với (giả sử) C #. Với sự đồng thời lạc quan, nó có xu hướng âm thầm thả các tệp khỏi dự án khi các đăng ký không đồng bộ. Ngay cả với đội ngũ kỷ luật tốt, phản hồi từ UI về tình trạng rất kém. Đây sẽ là một thảm họa trên một mô hình phức tạp. (-VS2010 - Tôi gần như sẽ xem xét rằng lỗ hổng hiển thị cho một dự án lớn).

• SSMS đi kèm với SQL Server - không thể đánh bại giá (+ SSMS).

• VS2010 vẫn chưa có kho lưu trữ thích hợp như (giả sử) PowerDesigner hoặc Oracle Designer. Bạn không thể dễ dàng truy vấn mô hình dữ liệu mà không cần cài đặt nó vào cơ sở dữ liệu. (- VS2010).

Nhìn chung, tôi sẽ đánh giá VS2010 về B-. Thật là vụng về trong một dự án cơ sở dữ liệu tương đối đơn giản với hai bảng thực tế và khoảng 15 chiều.

Mô hình dữ liệu lớn nhất tôi từng làm là cho một hệ thống quản lý vụ án, có khoảng 560 bảng. Tôi sẽ không đề xuất VS2010 cho một dự án có kích thước đó (tôi đã làm điều đó trên Oracle Designer). Về cơ bản, nó đang cố tỏ ra thông minh và mô hình không thực sự hoạt động tốt như vậy. Bạn tốt hơn với một công cụ lập mô hình tốt nhất như PowerDesigner hoặc chỉ sử dụng tạo tập lệnh bảng bằng tay.

SSMS đơn giản và đáng tin cậy nhưng thủ công. Bạn có khá nhiều quyền kiểm soát vô hạn đối với cách bạn muốn quản lý mô hình. Kết hợp nó với một trình quản lý lược đồ như Redgate SQL So sánh và có thể là một công cụ mô hình hóa tốt như PowerDesigner và bạn có gói tốt hơn nhiều so với VS2010.

Tóm tắt Tôi không chắc chắn tôi có thể trích dẫn bất kỳ tính năng hoặc lợi ích sát thủ nào ngoài việc tích hợp (có lẽ) với các giải pháp VS có chứa các dự án khác. Nếu bạn đã có VS2010 premium hoặc Ultimate thì bạn sẽ có được một công cụ phát triển cơ sở dữ liệu hơi thiếu sót với chuỗi công cụ .Net của bạn. Nó sẽ tích hợp các dự án DB vào giải pháp VS của bạn, vì vậy bạn có thể sử dụng nó để tạo các kịch bản triển khai sproc ít nhất.

Tuy nhiên, VS không có công cụ mô hình hóa để nói, vì vậy PowerDesigner hoặc thậm chí Erwin là tốt hơn về số đó. Quản lý lược đồ của Redgate tốt hơn nhiều và SQL So Pro khá rẻ (khoảng £ 400 IIRC). IMHO SSMS hoạt động tốt hơn nhiều cho việc phát triển T-SQL nhưng bạn chắc chắn có thể làm điều đó với VS2010.

VS2010 premium không rẻ hơn nhiều so với một công cụ mô hình hóa cơ sở dữ liệu tốt nhất và VS2010 cuối cùng ít nhất là đắt tiền. Với chi phí tích hợp chặt chẽ với dự án VS của bạn, bạn có thể có thể làm tốt hơn với các công cụ của bên thứ ba.

Một sự thay thế

Tôi đoán người ta không nên xỉa quá nhiều VS2010 mà không đề xuất ít nhất một phương án và nêu ra những ưu và nhược điểm của nó. Vì mục đích này, tôi sẽ đảm nhận một dự án lớn. Mặc dù tôi chủ yếu làm công việc A / P những ngày này tôi đã tham gia vào một dự án hơn 100 năm nhân viên, nơi tôi đã làm mô hình dữ liệu (và một số công việc phát triển) và một vài người khác trong phạm vi 10 nhân viên, nơi tôi chủ yếu làm việc như một nhà phân tích hoặc một nhà phát triển. Hầu hết tôi làm việc trên các hệ thống kho dữ liệu ngày nay nhưng các dự án lớn hơn chủ yếu là các ứng dụng. Dựa trên kinh nghiệm của tôi với các công cụ khác nhau, đây là một số gợi ý cho chuỗi công cụ thay thế:

• VS2010 chuyên nghiệp trở lên. Bạn có thể hoặc không muốn sử dụng các tính năng quản lý dự án cao cấp hoặc cuối cùng.
• Subversion, AnkhSVN và TortoiseSVN - Tốt hơn TFS bất kỳ ngày nào và chơi độc đáo với VS. Cũng khá dễ dàng để canh tác các kho lưu trữ địa phương cho các quy trình phát triển đồng thời.
• SSMS cho phát triển T-SQL - Quản lý dự án và tích hợp SC không tốt lắm nhưng hoạt động tốt cho công việc phát triển DB.
• Dự án DB VS2010 để theo dõi các tệp sproc - hơi vụng về nếu bạn đang sử dụng SSMS nhưng hoạt động tốt. Nó cũng sẽ tạo ra các kịch bản triển khai.
• PowerDesigner - Cách tốt hơn trong việc mô hình hóa cơ sở dữ liệu và quản lý các mục lược đồ DB. Nó cũng thực hiện UML nếu bạn muốn tham gia nhiều vào MDA. Nếu bạn muốn lái thiết kế DB của mình từ một mô hình đối tượng, bạn có thể xem xét Sparx EA thay thế. Nó thực hiện công việc tốt nhất của Meta CASE (mô hình meta mở rộng) của bất kỳ công cụ CASE nào tôi từng thấy, mặc dù mô hình cơ sở dữ liệu của nó để lại thứ gì đó mong muốn.
• SQL So sánh pro - Sử dụng công cụ này để tạo tập lệnh vá DB hoặc để kiểm tra tập lệnh vá thủ công (xem 1 bên dưới).
• Framemaker - Các tính năng phần mềm nhóm ổn định hơn và tốt hơn nhiều so với Word nếu bạn có nhiều nhà phân tích làm việc trên một thông số kỹ thuật. Nó cũng hỗ trợ bao gồm có điều kiện, do đó bạn có thể có các bản phát hành phiên bản của một thông số với các thay đổi WIP bị ẩn đi. MIF và MML giúp tích hợp các tài liệu API và từ điển dữ liệu vào các tài liệu cụ thể khá dễ dàng. Nó khá hữu ích để làm điều này vì bạn có thể tham chiếu chéo chúng trong thông số kỹ thuật. Neo nhãn văn bản làm cho tài liệu tham khảo chéo ổn định trong quá trình nhập lại. Bạn cũng có thể sử dụng TCS để đơn nguồn tài liệu thành đầu ra PDF, HTML và CHM.
• Trình theo dõi vấn đề nguồn mở - Nhiều trình theo dõi nguồn mở tốt (ví dụ TRAC, Bugzilla để đặt tên cho một cặp vợ chồng tôi đã sử dụng). Các nguồn mở dễ dàng sửa đổi hoặc tích hợp vào quy trình công việc tùy chỉnh và bạn không thể đánh bại giá.
• NUnit hoặc các công cụ kiểm tra khác - bất kỳ công cụ kiểm tra tự động nào phù hợp nhất với yêu cầu của bạn.
• Bất cứ điều gì trừ dự án MS - Được coi là có hại. Dự án MS rất hướng nội và buộc các kế hoạch dự án thành một mô hình không thể hiện hiệu quả sự không chắc chắn, rủi ro hoặc phụ thuộc vào các bên liên quan hoặc các bên thứ ba khác (xem 2 dưới đây).

Ưu điểm: Mô hình hóa cơ sở dữ liệu và quản lý lược đồ tốt hơn VS2010, hệ thống kiểm soát phiên bản tốt hơn, dễ dàng tùy chỉnh luồng công việc xây dựng và dự án, quản lý thông số kỹ thuật và tài liệu tốt hơn.

Nhược điểm: Nhiều nỗ lực hơn để tích hợp các công cụ, tích hợp DB hạn chế vào quá trình xây dựng.

Giả định: Giả định rằng việc kiểm soát quá trình thay đổi / phát hành quan trọng hơn quản lý phát hành tích hợp tự động hoặc tích hợp chặt chẽ cho các lược đồ DB. Cũng giả định rằng quản lý lược đồ DB tự động không đáng tin cậy 100%.

Không phải là công nghệ cao hay tích hợp trơn tru, nhưng đối với một dự án phức tạp, có lẽ bạn sẽ quan tâm đến việc kiểm soát hơn các tính năng tự động dễ thương. Tôi cho rằng bạn tốt hơn với một bộ công cụ giống tốt nhất và bất kỳ kịch bản thử nghiệm và xây dựng nhà sản xuất bia nào là cần thiết để tích hợp chúng. Chỉ cần cố gắng giữ cho bản dựng (a) tương đối dễ hiểu và (b) hoàn toàn tự động.

1. QA trên các bản vá DB. Trên một lược đồ lớn, bạn có thể muốn có một quy trình vá thủ công cho các hệ thống trực tiếp, đặc biệt nếu các bản vá liên quan đến di chuyển dữ liệu. Ví dụ, có thể mong muốn có các tập lệnh cuộn tiến và quay lại để hỗ trợ sao lưu thay đổi nếu cần thiết. Trong trường hợp này, bạn sẽ muốn có một cơ sở để kiểm tra rằng bản vá thực sự hoạt động đúng. Nếu bạn quản lý lược đồ cơ sở dữ liệu trong kho lưu trữ, bạn có thể kiểm tra các tập lệnh bằng cách thiết lập trước cơ sở dữ liệu và tạo cơ sở dữ liệu tham chiếu từ kho lưu trữ. Chạy tập lệnh vá trên cơ sở dữ liệu trước nên đồng bộ hóa nó với mô hình kho lưu trữ. Một công cụ so sánh lược đồ có thể được sử dụng để kiểm tra điều này.

2. Gần đây tôi đã thực hiện nhiều kho dữ liệu và công việc tích hợp hơn so với phát triển ứng dụng bespoke, vì vậy tôi gặp phải điều này thường xuyên hơn so với một nhóm phát triển trong hầu hết các trường hợp. Tuy nhiên, các công cụ và phương pháp quản lý dự án làm rất tốt việc quản lý các bên liên quan bên ngoài. Trong một dự án tích hợp như kho dữ liệu, tôi thực sự muốn thấy một công cụ quản lý dự án thực sự đẩy các phụ thuộc bên ngoài (tức là những thứ tôi không kiểm soát) khi đối mặt với quản lý chương trình. Trên bất kỳ dự án tích hợp không tầm thường nào, các phụ thuộc bên ngoài cho đến nay vẫn là những động lực lớn nhất gây lãng phí thời gian.

Tôi đã chơi với cách cấu trúc một câu trả lời cho câu hỏi này kể từ khi nó được đăng lần đầu. Điều này rất khó vì trường hợp của VS2010 không phải là về việc mô tả các tính năng và lợi ích của công cụ. Đây là về việc thuyết phục người đọc thực hiện một sự thay đổi cơ bản trong cách tiếp cận phát triển cơ sở dữ liệu của họ. Không dễ.

Có câu trả lời cho câu hỏi này từ các chuyên gia cơ sở dữ liệu dày dạn, với một hỗn hợp nền bao gồm DBA, nhà phát triển / dba và cả OLTP và kho dữ liệu. Tôi không thể tiếp cận điều này cho mọi khía cạnh của việc phát triển cơ sở dữ liệu trong một lần ngồi, vì vậy tôi sẽ thử và đưa ra một trường hợp cho một kịch bản cụ thể.

Nếu dự án của bạn phù hợp với các tiêu chí này, tôi nghĩ rằng có một trường hợp hấp dẫn cho VS2010:

• Nhóm của bạn đang sử dụng VS2010 để phát triển ứng dụng.
• Nhóm của bạn đang sử dụng TFS để kiểm soát nguồn và quản lý xây dựng.
• Cơ sở dữ liệu của bạn là SQL Server.
• Nhóm của bạn đã có hoặc quan tâm đến thử nghiệm tự động VS.

Nếu bạn đang đánh giá VS2010 để phát triển cơ sở dữ liệu, kinh thánh của bạn sẽ là Hướng dẫn cơ sở dữ liệu Visual Studio từ Visual Studio ALM Rangers . Bất kỳ trích dẫn nào không có tài liệu tham khảo sẽ được lấy từ tài liệu này.

Chúng ta đi thôi ...

Tại sao quá trình phát triển cơ sở dữ liệu khác với phát triển ứng dụng?

Dữ liệu. Nếu không có dữ liệu phiền phức đó, việc phát triển cơ sở dữ liệu sẽ là một sự tránh né. Chúng tôi chỉ có thể DROP mọi thứ trên mỗi bản phát hành và quên đi việc quản lý thay đổi rắc rối này.

Sự tồn tại của dữ liệu làm phức tạp quá trình thay đổi cơ sở dữ liệu vì dữ liệu thường được di chuyển, biến đổi hoặc tải lại khi các thay đổi được đưa ra bởi các nỗ lực phát triển ứng dụng ảnh hưởng đến hình dạng của các bảng của cơ sở dữ liệu hoặc các lược đồ dữ liệu khác. Trong suốt quá trình thay đổi này, dữ liệu chất lượng sản xuất và trạng thái hoạt động phải được bảo vệ trước những thay đổi có thể gây nguy hiểm cho tính toàn vẹn, giá trị và tính hữu ích của nó đối với tổ chức.

SSMS có gì sai?

Nó được gọi là SQL Server Management Studio vì một lý do. Là một công cụ độc lập, việc quản lý các nỗ lực phát triển của bạn là không thực tế nếu bạn sẽ tuân theo các thực tiễn tốt nhất được chấp nhận.

Chỉ riêng với các tập lệnh, để áp dụng một cách có ý nghĩa các thực tiễn kiểm soát nguồn đã thiết lập vào sự phát triển của bạn, bạn sẽ phải duy trì cả hai định nghĩa đối tượng (ví dụ: tập lệnh CREATE TABLE) VÀ thay đổi tập lệnh (ví dụ ALTER TABLE) VÀ làm việc chăm chỉ để đảm bảo chúng vẫn được đồng bộ hóa.

Chuỗi các phiên bản để thay đổi bảng trở nên khá nhanh chóng. Một ví dụ rất đơn giản:

-- 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))

Đến phiên bản 3, tập lệnh thay đổi cơ sở dữ liệu chứa:

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

Nếu phiên bản trực tiếp của cơ sở dữ liệu này là phiên bản 1 và phiên bản tiếp theo của chúng tôi là phiên bản 3, tập lệnh bên dưới sẽ là tất cả những gì cần thiết nhưng thay vào đó cả hai câu lệnh ALTER sẽ được thực thi.

ALTER TABLE dbo.Widget ADD Description VARCHAR(100)

5 năm của 4 tuần nước rút thêm vào một số kịch bản phiên bản giải trí và yêu cầu xử lý con người bổ sung để giảm thiểu tác động đến thời gian triển khai.

Vậy có gì sai với SSMS? Không, nó tốt cho những gì tốt cho việc quản trị và quản lý SQL Server. Những gì nó thậm chí không giả vờ làm là hỗ trợ nhà phát triển cơ sở dữ liệu với nhiệm vụ rất phức tạp (đôi khi) là quản lý thay đổi.

Nếu bạn không thể xây dựng mọi phiên bản cơ sở dữ liệu từ nguồn và nâng cấp lên bất kỳ phiên bản nào trong tương lai, kiểm soát nguồn của bạn sẽ bị hỏng. Nếu bạn không nghĩ vậy, hãy hỏi Eric chìm .

Điều gì về SSMS + <- chèn công cụ so sánh lược đồ ->?

Đây chắc chắn là một bước đi đúng hướng và lấy đi nhiều nỗ lực thủ công cần có để duy trì các tập lệnh. Nhưng (và nó lớn nhưng), thường có các bước thủ công liên quan.

Các công cụ so sánh lược đồ phổ biến có thể hoàn toàn tự động và được tích hợp vào quá trình xây dựng. Tuy nhiên, theo kinh nghiệm của tôi, thực tế phổ biến hơn là để so sánh được chạy thủ công, các tập lệnh kết quả được đánh dấu, kiểm tra để kiểm soát nguồn, sau đó được thực hiện thủ công để triển khai. Không tốt.

Bất cứ khi nào chúng ta có thể ngụy biện, con người phải tham gia vào quá trình xây dựng hoặc triển khai, chúng tôi đưa ra rủi ro và chúng tôi làm cho quá trình không thể lặp lại.

Nếu bạn và nhóm của bạn nằm trong số ít người có so sánh và triển khai lược đồ hoàn toàn tự động, hãy ngả mũ với bạn! Các bạn rất có thể sẽ cởi mở với những lợi ích mà VS2010 mang lại như:

• Bạn đã chấp nhận rằng các bước thủ công là nguy hiểm.
• Bạn thấy giá trị của tự động hóa.
• Bạn sẵn sàng đầu tư thời gian cần thiết để làm cho nó hoạt động.

Nếu bạn không thể tạo bản dựng trong một bước hoặc triển khai trong một bước duy nhất, quy trình phát triển và triển khai của bạn sẽ bị hỏng. Nếu bạn không nghĩ vậy, hãy hỏi Joel Spolsky .

Tại sao lại là VS2010?

Câu hỏi @NickChammas đặt ra là tìm kiếm các tính năng sát thủ chứng minh tại sao VS2010 là một công cụ thay đổi trò chơi để phát triển cơ sở dữ liệu. Tôi không nghĩ rằng tôi có thể làm cho trường hợp trên cơ sở đó.

Có lẽ về mặt hài hước, nơi những người khác nhìn thấy lỗ hổng trong công cụ này, tôi thấy những lý do mạnh mẽ để áp dụng:

• Bạn sẽ phải thay đổi cách tiếp cận của bạn.
• Bạn và nhóm của bạn sẽ bị buộc phải làm việc theo một cách khác.
• Bạn sẽ phải đánh giá tác động của mọi thay đổi, theo chiều dài, chi tiết.
• Bạn sẽ được hướng dẫn về hướng làm cho mọi thay đổi idempotent .

Nếu bạn là DBA duy nhất trong một dự án, quản lý tất cả các thay đổi đối với cơ sở dữ liệu, lý do này phải nghe có vẻ vô lý giáp với vô lý. Tuy nhiên, nếu bạn nghĩ rằng @BrentOzar có một điểm và một trong những quy tắc mới là DBA của mọi người , bạn sẽ cần kiểm soát thay đổi cơ sở dữ liệu theo cách mà mọi nhà phát triển trong nhóm có thể làm việc.

Việc áp dụng các dự án cơ sở dữ liệu có thể đòi hỏi một sự thay đổi tinh thần ( thói quen cũ khó phá vỡ ) đối với một số nhà phát triển hoặc ít nhất là một sự thay đổi trong quy trình hoặc quy trình công việc. Các nhà phát triển đã phát triển các ứng dụng cơ sở dữ liệu trong đó cơ sở dữ liệu sản xuất đại diện cho phiên bản hiện tại của cơ sở dữ liệu sẽ cần áp dụng cách tiếp cận dựa trên mã nguồn, nơi mã nguồn trở thành phương tiện để thay đổi cơ sở dữ liệu . Trong Visual Studio Database Project, dự án và mã nguồn là "Một phiên bản của sự thật" cho lược đồ cơ sở dữ liệu và được quản lý bằng các luồng công việc SCM có khả năng đã được nhà phát triển hoặc tổ chức sử dụng cho các phần khác của ngăn xếp ứng dụng của họ. Đối với dữ liệu, cơ sở dữ liệu sản xuất vẫn là "Một phiên bản của sự thật" như mong muốn.

Chúng tôi đã đi đến sự thay đổi cơ bản cần thiết để áp dụng thành công cách tiếp cận VS2010 để phát triển cơ sở dữ liệu

Coi cơ sở dữ liệu của bạn dưới dạng mã

Không còn thay đổi cơ sở dữ liệu trực tiếp. Mọi thay đổi cơ sở dữ liệu sẽ theo cùng một mẫu với thay đổi ứng dụng. Sửa đổi nguồn, xây dựng, triển khai. Đây không phải là một sự thay đổi hướng tạm thời từ Microsoft, đây là tương lai cho SQL Server . Cơ sở dữ liệu như mã ở đây để ở lại.

Nhà phát triển cơ sở dữ liệu xác định hình dạng của đối tượng cho phiên bản của ứng dụng, chứ không phải làm thế nào để biến đổi đối tượng hiện có trong công cụ cơ sở dữ liệu thành hình dạng mong muốn. Bạn có thể tự hỏi: Làm thế nào điều này được triển khai đối với cơ sở dữ liệu đã chứa bảng khách hàng? Đây là nơi công cụ triển khai đến để chơi. Như đã đề cập trước đây, công cụ triển khai sẽ lấy phiên bản đã biên dịch của lược đồ của bạn và so sánh nó với mục tiêu triển khai cơ sở dữ liệu. Công cụ phân biệt sẽ tạo ra các tập lệnh cần thiết để cập nhật lược đồ đích để phù hợp với phiên bản bạn đang triển khai từ dự án.

Vâng, có những công cụ khác theo một mô hình tương tự và đối với các dự án ngoài các ràng buộc mà tôi đã đặt vào câu trả lời của mình, chúng đáng để xem xét như nhau. Nhưng, nếu bạn đang làm việc với Visual Studio và Team Foundation Server ALM, tôi không nghĩ họ có thể cạnh tranh.

Có gì sai với các dự án cơ sở dữ liệu VS2010?

• Chúng không hoàn hảo . Nhưng nếu bạn nhận thức được những hạn chế và lĩnh vực vấn đề, bạn có thể giải quyết chúng.
• Các phong trào dữ liệu phức tạp vẫn đòi hỏi sự quan tâm và chú ý nhưng được phục vụ cho các kịch bản triển khai trước / sau.

Chỉnh sửa: Vậy quan điểm của bạn là gì?

@AndrewBickerton đã đề cập trong một bình luận rằng tôi chưa trả lời câu hỏi ban đầu nên tôi sẽ thử và tóm tắt "Tại sao tôi nên sử dụng Visual Studio 2010 qua SSMS để phát triển cơ sở dữ liệu của mình?" đây.

• SSMS không phải là một công cụ phát triển cơ sở dữ liệu. Có, bạn có thể phát triển TSQL với SSMS nhưng nó không cung cấp các tính năng IDE phong phú của VS2010.
• VS2010 cung cấp một khung để coi cơ sở dữ liệu của bạn dưới dạng mã.
• VS2010 mang phân tích mã tĩnh vào mã cơ sở dữ liệu của bạn.
• VS2010 cung cấp cho bạn các công cụ để tự động hóa hoàn toàn chu trình xây dựng-triển khai-thử nghiệm.
• SQL2012 và Visual Studio vNext mở rộng khả năng của các dự án cơ sở dữ liệu. Làm quen với VS2010 ngay bây giờ và bạn đã bắt đầu với các công cụ phát triển cơ sở dữ liệu thế hệ tiếp theo.

VS có thể xuất hiện tuyệt vời nếu bạn không biết SSMS hoặc đã sử dụng các công cụ của bên thứ 3. Các lỗ hổng trong VS nổi bật nếu bạn sử dụng các công cụ Red Gate để so sánh lược đồ, v.v. Và các plugin SSMS miễn phí cũng vậy.

Các bit điều khiển nguồn là sai lệch: những gì trong cơ sở dữ liệu sản xuất là bản sao tham chiếu của bạn. Không phải những gì nhà phát triển đang sử dụng. Xem

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

Tôi sử dụng rộng rãi Visual Studio (tốt, BIDS) cho thiết kế báo cáo SSRS và các gói SSIS. Tôi không thể làm rất tốt, nếu có, trong Management Studio. Visual Studio là một môi trường phát triển tích hợp và hoàn thiện hơn nhiều, và nó cũng kết nối với các hệ thống Kiểm soát nguồn tốt hơn nhiều. Và đó là tất cả phản ánh trong giá!

Thành thật mà nói, phiếu bầu của tôi được chuyển thẳng đến SQL Server Management Studio để thiết kế cơ sở dữ liệu, phát triển và quản trị (rõ ràng). Nó chỉ dễ dàng hơn để loại ra:

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

Sau đó bấm vào tất cả các vị trí thích hợp. SSMS là một bố cục tuyệt vời và hoàn toàn tuyệt vời để làm việc. Và bản chất tôi là một nhà phát triển phần mềm .NET. Nhưng khi nói đến thiết kế cơ sở dữ liệu và mã hóa, tôi sẽ chọn SSMS 11 lần trong số 10.

Không có cách thực hành tốt nhất, nhưng với dự án cơ sở dữ liệu VS 2010 và bộ điều khiển mã nguồn (VSS 2010, Subversion, v.v.), bạn có thể phiên bản cơ sở dữ liệu của mình.

Tôi khuyên bạn trước tiên nên thiết kế cơ sở dữ liệu của bạn trực tiếp vào SSMS. Sau khi cơ sở dữ liệu của bạn gần như sẵn sàng, hãy nhập nó vào dự án cơ sở dữ liệu VS 2010. Khi quá trình nhập được thực hiện, bạn phải luôn thêm tập lệnh mới vào dự án cơ sở dữ liệu của mình để theo dõi tất cả các sửa đổi. Bạn có thể sử dụng tính năng so sánh của dự án cơ sở dữ liệu để nhận tất cả các thay đổi từ máy chủ phát triển và nhập tất cả các tập lệnh đó trực tiếp vào dự án của bạn. Bây giờ bạn chỉ cần "cam kết" thay đổi của mình vào bộ điều khiển mã nguồn.

Với phương pháp này, bạn có thể có một cơ sở dữ liệu được phiên bản. Bạn có thể phát hiện phiên bản của từng sửa đổi và khôi phục các thay đổi của mình.

Đây không phải là lợi thế duy nhất. Với loại dự án này, bạn có thể so sánh bất kỳ cơ sở dữ liệu nào với dự án của mình để kịch bản thay đổi và với dấu nhắc lệnh SQL PowerShell, bạn có thể cập nhật tất cả các cơ sở dữ liệu của mình với cùng một tập lệnh: tập lệnh này là lược đồ XML của cơ sở dữ liệu của bạn. Nó sẽ chỉ thực hiện các lệnh cần thiết để cập nhật cơ sở dữ liệu của bạn. Bạn cũng có khả năng để thực hiện kiểm tra đơn vị trong cơ sở dữ liệu của bạn. Một bài viết tốt khác cho dự án cơ sở dữ liệu có sẵn ở đây . Với tính năng triển khai, bạn có thể có tập lệnh trước và tập lệnh. Với các tập lệnh này, bạn có thể xác thực hoặc chèn dữ liệu vào các bảng hệ thống của mình.

Đây là một bước thủ tục tốt cho dự án cơ sở dữ liệu.

Tôi sử dụng SSMS nhiều hơn tôi làm VS2010 vì nó ở đó khi tôi cài đặt SQL Server. Đó có lẽ là điều quan trọng nhất tại sao SSMS được sử dụng nhiều hơn VS2010, IMHO.

Tôi cũng thấy rằng các nhà cung cấp như Red-Gate đang đưa ra các công cụ tích hợp với SSMS và không nhất thiết phải là VS2010. Điều này có thể tích cực ở chỗ nó cho phép bạn cải thiện SSMS mà Microsoft không có. Một ví dụ về điều này là Kiểm soát nguồn SQL của Red-Gate, đây là một tiện ích bổ sung cho SSMS cho phép bạn kết nối SSMS với hệ thống Kiểm soát nguồn của công ty bạn cho dù đó là Visual Team Foundation hay những gì có bạn. VS2010 có tích hợp sẵn này nhưng so với giá của công cụ Reg-Gate, tôi chỉ tiết kiệm được một loạt tiền mà không phải mua VS2010.

Tôi nghĩ về tổng thể nó tùy thuộc vào sở thích, bạn làm việc với những gì bạn cảm thấy thoải mái. Nếu bạn đang đào tạo một người mới và bạn đào tạo họ trên VS2010 thì điều đó sẽ trở thành sở thích của họ vì họ biết cách giải quyết.

Nếu bạn bắt đầu chơi với SQL Server 2012, bạn có thể nhận thấy rằng SSMS đang trang điểm cho VS2010 chậm nhưng chắc chắn. Vì vậy, cuối cùng bạn có thể không thể nói sự khác biệt giữa chúng.