Thực tiễn tốt nhất để tối đa hóa tính di động trong SQL Server 2016


8

Khi nói đến việc phát triển nguyên mẫu của một giải pháp, thường thì các công nghệ vẫn chưa được quyết định và có thể không giống với những gì sẽ được sử dụng trong sản phẩm hoàn chỉnh.

Trong trường hợp này, tôi có xu hướng sử dụng Microsoft SQL Server viết các truy vấn theo tiêu chuẩn nhất có thể để đơn giản hóa việc di chuyển cuối cùng sang máy chủ khác.

Có cách nào hoặc một số thực tiễn đã biết để thực thi việc sử dụng SQL tiêu chuẩn qua phương ngữ T-SQL trực tiếp trong SQL Server hoặc thông qua SQL Server Management Studio (SSMS) không?


3
Tính di động là một mục tiêu sách giáo khoa tốt, nhưng nó hiếm khi xảy ra trong thực tế. Khi bạn có lựa chọn giữa cú pháp tiêu chuẩn ( <>) và không chuẩn ( !=), khi không có sự thỏa hiệp về hiệu suất hoặc khả năng bảo trì, tôi luôn chọn tiêu chuẩn. Nhưng khi nói đến các chi phí khác, hoặc không có tiêu chuẩn tương đương, tôi khai thác và sở hữu độc quyền. Những thứ bạn từ bỏ chỉ để có khả năng chuyển đổi hoàn toàn nền tảng bán buôn chỉ là không đáng.
Aaron Bertrand

6
Khả năng di chuyển thời gian duy nhất là mục tiêu thực tế là khi bạn viết một ứng dụng cần tích hợp với nhiều nền tảng cùng lúc vì khách hàng của bạn sử dụng các nền tảng khác nhau. Ngay cả sau đó, trừ khi bạn muốn chức năng bị hạn chế và hiệu suất là khủng khiếp trên tất cả các nền tảng, tôi sẽ gửi các gói có nghĩa là tận dụng các tính năng của các nền tảng riêng lẻ.
Aaron Bertrand

1
Chỉ tò mò; trong lịch sử, bạn đã từng thay đổi hệ thống cơ sở dữ liệu mà một ứng dụng đang sử dụng cho một lớp khác tương đương (ví dụ: Oracle -> SQLS) chưa? Tôi chưa
Caius Jard

2
Một điều khác tôi đã tò mò về; bao nhiêu nguyên mẫu của bạn tồn tại một cách hợp lý để trở thành một hệ thống cấp sản xuất đầy đủ? Hầu hết các nguyên mẫu của tôi chia sẻ gần như không có khía cạnh nào với các hệ thống đầy đủ được viết ra sau khi proto đã chứng minh một khái niệm và đưa ra một số cách tiếp cận hợp lý về cách một giải pháp nên nhìn; bạn đang làm cho các nguyên mẫu của bạn quá hoàn hảo / bám vào chúng quá lâu?
Caius Jard

Câu trả lời:


16

Người dùng Aaron Bertrand đã đưa ra một số ý kiến ​​phù hợp với suy nghĩ của tôi về câu hỏi của bạn. Đây là một thách thức khung hơn là một câu trả lời cho câu hỏi cụ thể của bạn, nhưng tôi nghĩ rằng nó có giá trị để xem xét trong bối cảnh này.

Tính di động là một mục tiêu sách giáo khoa tốt, nhưng nó hiếm khi xảy ra trong thực tế.

Nếu bạn phải thay đổi nền tảng tại một số điểm, sẽ có những thay đổi cần thiết cho ứng dụng, cơ sở dữ liệu và có thể nhiều thứ khác. Nếu bạn có thể hơi "bất khả tri" mà không cần quá nhiều nỗ lực, thì tốt thôi. Nhưng đó thực sự là một quyết định kinh doanh tồi khi sử dụng nó làm mục tiêu thiết kế.

Có nhiều nơi trực tuyến nơi mọi người thảo luận về nhược điểm hoặc lập trình theo cách này, đây là một trong số đó tôi thấy khá hấp dẫn:

Các lớp trừu tượng cơ sở dữ liệu phải chết!

The Fallacy Fallacy

Tác giả sử dụng một đối số mà tôi nghe thấy mọi lúc: Nếu bạn sử dụng một lớp trừu tượng tốt, bạn sẽ dễ dàng chuyển từ $ this_database sang $ other_database trên đường.

Thật vớ vẩn. Nó không bao giờ dễ dàng.

Trong bất kỳ ứng dụng hỗ trợ cơ sở dữ liệu không tầm thường nào, không ai nghĩ chuyển đổi cơ sở dữ liệu là một vấn đề dễ dàng. Nghĩ rằng "việc chuyển đổi sẽ không đau đớn" là một tưởng tượng.

Các kỹ sư giỏi cố gắng chọn các công cụ tốt nhất cho công việc và sau đó làm mọi thứ có thể để tận dụng các tính năng mạnh mẽ và độc đáo nhất của công cụ của họ. Trong thế giới cơ sở dữ liệu, điều đó có nghĩa là gợi ý cụ thể, lập chỉ mục, kiểu dữ liệu và thậm chí cả các quyết định cấu trúc bảng. Nếu bạn thực sự giới hạn bản thân trong tập hợp các tính năng phổ biến trên tất cả các RDBMS chính, thì bạn đang tự làm cho mình và khách hàng của mình một sự bất đồng lớn.

Điều đó không khác gì khi nói "Tôi đang giới hạn bản thân mình trong tập hợp con của PHP giống với Perl và C, bởi vì tôi có thể muốn chuyển đổi ngôn ngữ một ngày và 'không đau' chuyển mã của tôi."

Điều đó không xảy ra.

Chi phí chuyển đổi cơ sở dữ liệu sau khi một ứng dụng được phát triển và triển khai là khá cao. Bạn có thể thay đổi lược đồ và chỉ mục, thay đổi cú pháp, tối ưu hóa và điều chỉnh công việc để làm lại, gợi ý để điều chỉnh hoặc loại bỏ, v.v. Thay đổi mysql_foo () thành oracle_foo () thực sự là vấn đề ít nhất của bạn. Bạn sẽ chạm vào hầu hết, nếu không phải tất cả, về SQL của bạn - hoặc ít nhất bạn sẽ cần xác minh nó.

Điều đó không có vẻ "không đau" đối với tôi.


11

Không thi hành STD SQL.

Trước tiên hãy quyết định DBMS nào bạn sẽ sử dụng theo nhu cầu của dự án của bạn và tận dụng lợi thế của nó.


9

Không hẳn vậy.

SET FIPS_FLAGGER 'FULL'.

Điều này in ra một cảnh báo cho SQL không chuẩn - nhưng một số cảnh báo là

  • Tôi không chắc chắn tiêu chuẩn cụ thể này sử dụng (và nghi ngờ nó có thể là SQL 92)
  • Từ một thử nghiệm nhanh, điều này không phàn nàn về việc sử dụng +toán tử cho nối chuỗi hoặc các hàm độc quyền như GETDATE()vậy có vẻ không toàn diện.

3

"thường các công nghệ chưa được quyết định"

Tôi sẽ nói điều này hoàn toàn KHÔNG phải là trường hợp trong kinh nghiệm của tôi. Trong thực tế tôi không tin rằng tôi đã từng nghe về điều này ngoại trừ có lẽ một cái gì đó rất nhỏ.

Thông thường điều này được thiết lập và giải pháp mới dự kiến ​​sẽ sử dụng những gì đã được sử dụng.

Tôi đồng ý với những người bình luận ở trên rằng ngay cả khi nó chưa được thiết lập, bạn cần thiết lập điều đó trước khi bạn bắt đầu viết truy vấn và mã khác. Mặt khác, bạn chỉ có khả năng cho phép bản thân nỗ lực lãng phí rất nhiều trong việc viết lại ngay lập tức.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.