Nhược điểm để "VỚI SCHEMABINDING" trong SQL Server?

Question

Tôi có một cơ sở dữ liệu với hàng trăm bảng được đặt tên lúng túng trong đó (CG001T, GH066L, v.v.) và tôi có quan điểm trên mỗi cái với tên "thân thiện" (xem "KHÁCH HÀNG" là "CHỌN * TỪ GG120T", cho thí dụ). Tôi muốn thêm "WITH SCHEMABINDING" vào chế độ xem của mình để tôi có thể có một số lợi thế được liên kết với nó, như có thể lập chỉ mục chế độ xem vì một số lượt xem có các cột được tính toán đắt tiền khi tính toán.

Có những nhược điểm nào để SCHEMABINDING các chế độ xem này không? Tôi đã tìm thấy một số bài viết mơ hồ ám chỉ đến những nhược điểm, nhưng không bao giờ đi sâu vào chúng một cách chi tiết. Tôi biết rằng một khi xem là schemabound, bạn không thể thay đổi bất cứ điều gì mà sẽ ảnh hưởng đến xem (ví dụ, một cột datatype hoặc collation) mà không đầu tiên thả xem, do đó, đó là một, nhưng ngoài đó? Dường như khả năng lập chỉ mục chính nó sẽ vượt xa nhược điểm của việc lập kế hoạch sửa đổi lược đồ của bạn một cách cẩn thận hơn.

Answer 1

Không có gì cả. Nó an toàn hơn. chúng tôi sử dụng nó ở mọi nơi.

Answer 2

Bạn sẽ không thể thay đổi/xóa bảng, trừ khi bạn thả chế độ xem trước.

Answer 3

Nếu các bảng này là từ ứng dụng của bên thứ ba (chúng nổi tiếng vì cố gắng ẩn bảng), bạn gây ra và nâng cấp lên thất bại nếu nó cố gắng thay đổi bất kỳ bảng nào trong số này.

Bạn chỉ cần thay đổi các chế độ xem mà không cần tìm kiếm trước khi cập nhật/nâng cấp và sau đó đặt chúng trở lại. Giống như những người khác đã đề cập. Chỉ cần thực hiện một số quy hoạch, kỷ luật, v.v.

Answer 4

Một nhược điểm là nếu bạn vẽ sơ đồ chế độ xem, nó chỉ có thể tham chiếu các chế độ xem sơ đồ khác.

Tôi biết điều này vì tôi đã cố gắng vẽ sơ đồ một khung nhìn và đã gặp thông báo lỗi cho tôi biết rằng nó không thể được ghi lại bởi vì một trong các chế độ xem khác mà nó tham chiếu cũng không được ghi lại.

Hậu quả duy nhất của việc này là nếu bạn đột nhiên muốn cập nhật chế độ xem sơ đồ để tham khảo một số chế độ xem mới hoặc chế độ xem hiện tại, bạn có thể phải tìm hiểu chế độ xem mới hoặc chế độ xem hiện tại. Trong trường hợp đó, bạn sẽ không thể cập nhật chế độ xem và hy vọng các nhà phát triển cơ sở dữ liệu của bạn biết cách làm việc với chế độ xem sơ đồ.

Answer 5

Oh, có chắc chắn nhược điểm để sử dụng SCHEMABINDING - đây xuất phát từ thực tế, SCHEMABINDING, đặc biệt là khi kết hợp với các cột tính "ổ khóa" các mối quan hệ và làm cho một số "thay đổi không đáng kể" darn gần như không thể.

1. Tạo bảng.
2. Tạo UDF SCHEMABOUND.
3. Tạo cột ĐƯỢC TẠM DỪNG có tính toán tham chiếu đến UDF.
4. Thêm cột INDEX trên cột được đề cập.
5. Cố gắng cập nhật UDF.

Chúc bạn may mắn!

1. Không thể bỏ hoặc thay đổi UDF vì SCHEMABOUND.
2. Không thể xóa COLUMN vì COLUMN được sử dụng trong INDEX.
3. Không thể thay đổi COLUMN vì nó được TẮT.

Vâng, frak. Có thật không..!?! Ngày của tôi vừa trở thành một PITA. (Bây giờ, các công cụ như ApexSQL Diff có thể xử lý này khi được cung cấp với lược đồ sửa đổi, nhưng vấn đề ở đây là tôi thậm chí không thể sửa đổi lược đồ để bắt đầu!)

Tôi không chống lại SCHEMABINDING, tâm trí (và nó cần thiết cho một UDF trong trường hợp này), nhưng Tôi chống lại không có một cách (mà tôi có thể tìm thấy) để "tạm thời vô hiệu hóa" SCHEMABINDING.

Answer 6

Nhược điểm khác là bạn cần phải sử dụng tên tiêu chuẩn schema cho tất cả mọi thứ: Bạn sẽ nhận được một tải trọng của các thông báo lỗi như thế này:

Không thể schema bind xem 'xem' vì tên 'bảng' không hợp lệ cho ràng buộc lược đồ. Tên phải ở định dạng hai phần và một đối tượng không thể tự tham chiếu .

Đồng thời để 'tắt' chế độ xem bạn thay đổi chế độ xem yêu cầu bạn xác định lại câu lệnh chọn của chế độ xem. Tôi nghĩ rằng điều duy nhất bạn không cần phải xác định lại là bất kỳ khoản trợ cấp nào. Điều này đặt tôi ra rất nhiều như ghi đè lên xem có vẻ như một hoạt động vốn không an toàn.

Một chút giống như cách thêm không ràng buộc null buộc bạn phải ghi đè lên kiểu dữ liệu của cột - khó chịu! Bạn cũng sẽ phải xác định lại bất kỳ chế độ xem hoặc thủ tục nào khác phụ thuộc vào đối tượng liên kết lược đồ bạn muốn thay đổi ... điều này có nghĩa là bạn có thể phải xác định lại (và có thể ngắt) một loạt các hàm và chế độ xem lớn để thêm (ví dụ) một ràng buộc không null vào một cột.

Cá nhân tôi nghĩ điều này không thực sự đại diện cho giải pháp và tốt hơn là có một quy trình phong nha nhờ đó mọi thay đổi cơ sở dữ liệu được áp dụng tự động để không phải là một cơn ác mộng để thay đổi cơ sở dữ liệu. Bằng cách đó, bạn có thể có tất cả các chức năng quan điểm của bạn giảm xuống và tái tạo lại từ đầu (chúng được kiểm tra trên tạo anyway) như là một phần của quá trình khi bạn áp dụng thay đổi cho bảng.

Answer 7

này có vẻ như một nhược điểm đối với tôi (# 's là của tôi):

Cannot create index on view "###.dbo.###" because it uses a LEFT, RIGHT, or FULL OUTER join, and no OUTER joins are allowed in indexed views. Consider using an INNER join instead. 

tôi kinda cần LEFT tôi tham gia. This SO question có liên quan.

Answer 8

Khi sử dụng khung kiểm tra đơn vị tSQLt, bạn sẽ gặp các vấn đề và sẽ cần giải pháp khi sử dụng phương thức FakeTable, điều này sẽ không cho phép bạn giả mạo bảng được liên kết với chế độ xem với sơ đồ.

Answer 9

Các âm bản được đề cập hầu như không lớn hơn thực hành tốt nhất này kể từ SQL Svr 2005. Nó tránh được việc tạo bảng đáng sợ. Một tiêu cực lớn đối với tôi là sprocs bị ràng buộc lược đồ, funcs, views, không thể bao gồm cơ sở dữ liệu "nước ngoài" như db chủ, vì vậy bạn có thể ném tất cả các công cụ hệ thống thời gian thực vào thùng rác, trừ khi, ví dụ, lõi sản xuất của bạn cơ sở dữ liệu nằm bên trong chính. Đối với tôi, tôi không thể đối phó với cuộc sống mà không có đồ sys. Tất nhiên không phải tất cả quá trình xử lý đều đòi hỏi hiệu năng không có đường ống và kết quả nhanh và chậm có thể được kết hợp đồng thời trong các lớp lớp dữ liệu cao hơn.

Answer 10

Nếu công cụ của bạn (ssms, vv) không xử lý các thay đổi lược đồ thất bại trên đối tượng cơ sở tốt/thanh lịch, bạn có thể gây ra một số hỗn loạn thực sự.Đó là những gì tôi đang ngồi với bây giờ, và tôi nhận ra rằng đây là một trường hợp rìa