Làm thế nào để bạn (Đơn vị) Kiểm tra lược đồ cơ sở dữ liệu?

Question

Khi có một số người làm việc trong một dự án, tất cả những ai có thể thay đổi giản đồ cơ sở dữ liệu, cách đơn giản nhất để kiểm tra đơn vị/kiểm tra/xác minh nó là gì? Đề xuất chính mà chúng tôi đã có cho đến nay là viết các bài kiểm tra cho mỗi bảng để xác minh tên cột, các ràng buộc, v.v.

Có ai khác đã làm bất cứ điều gì tương tự/đơn giản hơn không? Chúng tôi đang sử dụng C# với SQL Server, nếu điều đó tạo ra bất kỳ sự khác biệt thực sự nào.

Cập nhật:

• Các phân đoạn của dự án chúng tôi đang làm việc trên đang sử dụng gói SSIS để làm phần lớn công việc do đó rất ít mã C# để viết bài kiểm tra đơn vị agains.
• Mã để tạo bảng/thủ tục lưu trữ được trải rộng trên các tệp SQL. Do hệ thống xây dựng, chúng tôi có thể duy trì một tệp dự án VS DB riêng biệt, nhưng tôi không chắc chắn cách thức đó cũng sẽ giúp chúng tôi xác minh lược đồ.

Answer 1

Một câu trả lời có thể là sử dụng Visual Studio cho nhà phát triển Cơ sở dữ liệu và giữ cho lược đồ của bạn trong kiểm soát nguồn với phần còn lại của mã. Điều này cho phép bạn thấy sự khác biệt và bạn có được một lịch sử của những người đã thay đổi những gì.

Hoặc bạn có thể sử dụng công cụ như SQLCompare để xem những gì đã được sửa đổi trong một cơ sở dữ liệu so với một cơ sở dữ liệu khác.

Answer 2

Đó là một câu hỏi thú vị! Có rất nhiều công cụ để thử nghiệm các thủ tục được lưu trữ nhưng không phải để kiểm tra lược đồ cơ sở dữ liệu.

Bạn không thấy rằng các bài kiểm tra đơn vị được viết cho mã thường tìm thấy bất kỳ vấn đề nào với lược đồ cơ sở dữ liệu?

Một cách tiếp cận mà tôi đã sử dụng là viết các thủ tục được lưu trữ để sao chép dữ liệu thử nghiệm từ lược đồ của nhà phát triển sang lược đồ kiểm tra. Điều này là khá thô và sẵn sàng như các thủ tục được lưu trữ thường sụp đổ khi họ đi qua bất kỳ sự khác biệt giữa các lược đồ nhưng nó cảnh báo bạn với bất kỳ thay đổi bạn đã không được nói về.

Và chỉ định một người nào đó làm DBA giám sát các thay đổi đối với giản đồ?

Answer 3

Cơ sở dữ liệu quan hệ (của bạn) thực hiện hai điều theo như tôi quan tâm: 1) Giữ dữ liệu và 2) Giữ mối quan hệ giữa dữ liệu.

Dữ liệu đang lưu giữ không phải là hành vi, do đó bạn sẽ không kiểm tra nó

Và để đảm bảo các mối quan hệ chỉ sử dụng các ràng buộc. Rất nhiều ràng buộc. Khắp nơi.

Answer 4

Điều này không thực sự phù hợp với mô hình thử nghiệm đơn vị. Tôi sẽ đề nghị phiên bản kiểm soát lược đồ và hạn chế quyền truy cập ghi vào một thành viên nhóm đủ điều kiện như DBA hoặc trưởng nhóm, những người có thể xác thực bất kỳ thay đổi được yêu cầu nào đối với toàn bộ ứng dụng. Thay đổi giản đồ không nên được thực hiện một cách bất ngờ.

Answer 5

Bạn không thấy rằng các bài kiểm tra đơn vị được viết cho mã thường tìm thấy bất kỳ vấn đề nào với lược đồ cơ sở dữ liệu?

Giả định này, tất nhiên, kiểm tra của bạn sẽ kiểm tra mọi thứ.

Answer 6

Tôi đã phải làm loại điều này trước đây, mặc dù không phải trong C#.Để bắt đầu, tôi đã xây dựng một công cụ di chuyển lược đồ, dựa trên các cuộc thảo luận tại Ode to Code (page 1 of 5) (cũng có các công cụ hiện có để thực hiện những việc tương tự). Quan trọng hơn, công cụ di chuyển mà tôi đã tạo cho phép bạn chỉ định cơ sở dữ liệu bạn đã áp dụng các thay đổi và phiên bản bạn muốn áp dụng. Sau đó, sau một phương pháp thử nghiệm đầu tiên, bất cứ khi nào tôi cần thay đổi lược đồ, tôi sẽ viết một kịch bản thử nghiệm để tạo cơ sở dữ liệu thử nghiệm, áp dụng các thay đổi phiên bản trước khi kịch bản thay đổi đích của tôi, thêm một số dữ liệu. kiểm tra và xác nhận rằng dữ liệu ở trạng thái dự kiến.

Mục tiêu chính của tôi với điều này là để xác nhận rằng không có dữ liệu nào bị mất hoặc bị hỏng trong quá trình di chuyển giản đồ, không kiểm tra cụ thể rằng lược đồ ở trong một trạng thái cụ thể. Cần có nhận thức tốt về bộ dữ liệu sản xuất của bạn, vì vậy bạn có thể ghi dữ liệu mẫu đại diện cho các thử nghiệm.

Có thể gây tranh cãi nếu điều này được coi là kiểm tra đơn vị hoặc thử nghiệm tích hợp. Tôi sẽ có xu hướng xem xét nó thử nghiệm tích hợp, dựa trên thực tế là tôi không muốn chạy thử nghiệm cũ mỗi khi tôi lặp lại mã của tôi. Bất cứ điều gì bạn muốn gọi nó, tôi thấy nó là một công cụ hữu ích cho tình huống đó.