Các nhà phát triển có nên được phép sử dụng LocalDB so với một phiên bản phát triển của YouTube không?

Giống như mạch của câu hỏi đã được đăng ở đây trước đây xung quanh "Các nhà phát triển có thể truy vấn cơ sở dữ liệu sản xuất không? " Tôi muốn nhận được suy nghĩ của bạn về một chủ đề đặc biệt khó chịu khác!

Nhiều công ty ngăn các nhà phát triển cài đặt SQL Server Express và tương tự trên các máy phát triển, thay vào đó thúc đẩy việc sử dụng Máy chủ SQL phát triển tập trung.

Cụ thể điều này được thực hiện để đảm bảo:

• Mức độ nhất quán giữa các máy chủ phát triển và sản xuất
  
• Khả năng chứng minh và xác nhận bất kỳ bản vá nào ở trên
  
• Bảo mật dữ liệu; chỉ dữ liệu trên các máy chủ phát triển được sử dụng để phát triển
  
• Khả năng phục hồi; dữ liệu có thể phục hồi và vẫn được sao lưu
  
• Sự khác biệt đối chiếu có thể gây ra vấn đề khi chuyển sang sản xuất

Đối với tôi tất cả các đối số này là đặc biệt không hợp lệ, có lẽ ngoại trừ các đối số vá; nhưng nếu cơ sở dữ liệu trên máy cục bộ hoàn toàn được sử dụng cho các hoạt động phát triển và không thử nghiệm, thì việc vá lỗi sẽ được chứng minh khi một ứng dụng được chuyển qua Test / UAT, v.v. đến Sản xuất.

Đối chiếu dường như không phải là một lý do hợp lệ, vì nếu đây là mối quan tâm đối với cơ sở dữ liệu thì nên đặt nó khi nó được tạo. Chỉ SharePoint và SCCM có vấn đề xung quanh vấn đề này theo như tôi biết;)

Bây giờ, giả sử nó CHỈ để phát triển và cơ sở dữ liệu sẽ không được "chuyển" sang sản xuất và các chuyển động duy nhất sẽ là:

• Các tập lệnh đã tạo cơ sở dữ liệu đang được tạo để triển khai để sản xuất
• Sao lưu từ các hệ thống bên thứ ba "sản xuất" đang được khôi phục và cắt bớt khi thích hợp để xác nhận và phát triển

Bất cứ ai có thể nhìn thấy bất kỳ vấn đề? Tui bỏ lỡ điều gì vậy?

Tôi đoán một trong những mối quan tâm lớn nhất sẽ là khả năng cho các trường hợp db cục bộ sắp hết hạn, nhưng đó là vấn đề quản lý phần mềm, không phải là DBA một IMO.

Đúng. Tất cả các nhà phát triển nên có một phiên bản cục bộ của SQL Server VÀ một phiên bản máy chủ SQL được chia sẻ. Chúng tồn tại cho các mục đích khác nhau. Cả hai đều cần thiết.

Có lẽ môi trường hiện tại của bạn trông như thế này?

Ở trên, một số nhà phát triển đang soạn thảo các thay đổi và triển khai chúng vào cơ sở dữ liệu SQL Developer chung. Thật tệ. Microsoft MVP Troy Hunt ghi lại một số điểm đau đớn của phương pháp cổ xưa này, tại đây . Những cái chính là ...

1. Không có khả năng kiểm soát nguồn thích hợp. LỚN!
2. Không có khả năng điều chỉnh hiệu suất mà không có quyền cấp máy chủ.
3. Không có khả năng thử nghiệm mà không ảnh hưởng đến người khác.

Mô hình này gây ra xung đột nhà phát triển. Một triệu chứng của cuộc xung đột là cơ sở dữ liệu ngổn ngang. Nhiều cơ sở dữ liệu được tạo ra khi các nhà phát triển săn tìm một không gian an toàn, biệt lập để thực hiện công việc của họ. Có một số lý do tổ chức bám vào mô hình này. Đầu tiên là họ chưa đầu tư vào một hệ thống kiểm soát nguồn thích hợp . Một điều nữa là họ chỉ đơn giản là thừa hưởng mẫu thiết kế này và không thể bận tâm thay đổi nó. Microsoft đã dần dần di chuyển ra khỏi mô hình này và vào một cái gì đó giống như thế này ...

Trong sơ đồ trên, mỗi nhà phát triển sử dụng Visual Studio để viết và lưu các thay đổi cơ sở dữ liệu của mình vào một phiên bản cục bộ của SQL Server. Những thay đổi cục bộ đó sau đó được đồng bộ hóa thành một hệ thống kiểm soát nguồn thích hợp. Tại đây, mỗi nhà phát triển có thể thiết kế và thử nghiệm trong một môi trường nơi những thay đổi của anh ta sẽ không ảnh hưởng đến bất kỳ ai khác cho đến khi đăng ký. Và tại thời điểm đó xung đột sẽ được giải quyết.

Cơ sở dữ liệu cục bộ được sử dụng ở trên có thể là phiên bản LocalDB, Express hoặc Developer. Simple-Talk thực hiện một công việc tuyệt vời cân nhắc ưu và nhược điểm của mỗi ở đây . Có một lý do Microsoft đã tạo ra rất nhiều sự lựa chọn cho cơ sở dữ liệu phát triển cục bộ: LocalDB, Express, Developer .. chúng ta nên sử dụng chúng!

Nếu bạn cần chọn, thật khó để không tranh luận rằng mọi nhà phát triển đều cài đặt phiên bản SQL Server Developer phiên bản cục bộ . Nó hoàn toàn miễn phí và có tính năng tương đương với phiên bản Enterprise. Nó sẽ cho phép toàn bộ nhóm của bạn khám phá và thiết kế trong toàn bộ ngăn xếp Microsoft BI (SQL Server, SSIS, SSRS và SSAS) một cách an toàn.

Chúng tôi vẫn có thể giữ cơ sở dữ liệu chung, nhưng nó không nên để phát triển, nó nên để thử nghiệm. Đó là một máy chủ nơi cài đặt cấp hệ thống đồng bộ với sản xuất. Phần cứng, HĐH, bản vá lỗi, v.v.

Đối với tôi tất cả những lập luận này đặc biệt không hợp lệ

Đồng ý. Nhưng họ không đến với chúng ta. Tại sao?

Mức độ nhất quán giữa các máy chủ phát triển và sản xuất

việc vá lỗi sẽ được chứng minh khi một ứng dụng tiến triển thông qua Test

Việc vá lỗi có thể khắc phục sự ổn định và các vấn đề tham nhũng dữ liệu, điều này sẽ gây khó khăn cho các nhà phát triển. Nó nên được thực hiện trên các máy phát triển bất kể.

Bảo mật dữ liệu; chỉ dữ liệu trên các máy chủ phát triển được sử dụng để phát triển

Thật hữu ích khi tách "cái nên là" khỏi "cái gì là". Các nhà phát triển kết thúc với dữ liệu nhạy cảm (không nhất thiết là PII, nhưng cũng không miễn phí) trên cơ sở dữ liệu của họ. Nó xảy ra.

Khả năng phục hồi; dữ liệu có thể phục hồi và vẫn được sao lưu

Siêu quan trọng.

Sự khác biệt đối chiếu có thể gây ra vấn đề khi chuyển sang sản xuất

Chỉ SharePoint và SCCM có vấn đề xung quanh vấn đề này

Bất cứ điều gì sử dụng bảng tạm thời sẽ có vấn đề này. Nó cực kỳ phổ biến. Bạn không bao giờ nhận thấy điều đó bởi vì hầu hết mọi người đi đối chiếu tiêu chuẩn ở nơi đầu tiên.

giả sử nó CHỈ để phát triển và cơ sở dữ liệu sẽ không được "chuyển" sang sản xuất

Tại sao chúng ta sẽ cho rằng? Mọi thứ thường đi từ phát triển đến sản xuất. Làm thế nào khác để bạn có được sản xuất lần đầu tiên? Kịch bản thuần túy? Không nhất thiết khi ứng dụng đã được sản xuất trước một thời gian.

Tôi đoán một trong những mối quan tâm lớn nhất sẽ là khả năng cho các trường hợp db cục bộ sắp hết hạn, nhưng đó là vấn đề quản lý phần mềm, không phải là DBA một IMO.

Bạn chỉ cần đưa ra một tuyên bố về những gì bạn làm và không hỗ trợ và tại sao.

LocalDB là một phần cốt lõi của SSDT và không thể tránh khỏi. Tuy nhiên, nó không thể truy cập từ xa và không có thành phần lập lịch (Express có vấn đề tương tự). Do đó, nó thường không được hỗ trợ bởi các DBA liên quan đến sao lưu, bảo trì và kiểm tra tính toàn vẹn.

Nhưng hợp nhất với các máy chủ phát triển tập trung vẫn có ý nghĩa. Và bây giờ, Phiên bản dành cho nhà phát triển là miễn phí, việc chứng minh có nhiều hơn trong số chúng thậm chí còn dễ dàng hơn.

Về mặt khái niệm, bạn đang đi đúng hướng. Đối với một tổ chức có quy trình phát triển trưởng thành / Vòng đời phát triển phần mềm (SDLC) bao gồm kiểm soát mã nguồn, tích hợp liên tục (CI), kiểm tra tự động và nhóm CNTT biết cách quản lý các môi trường và máy trạm khác nhau để giữ chúng đồng bộ liên quan đến phần mềm và cấp độ bản vá và các nhà phát triển có kỷ luật rằng a) tuân thủ quy trình, b) làm việc cùng nhau và c) làm việc với CNTT, sau đó có 50 (hoặc nhiều) DB phát triển có thể hoạt động:

• Có, phần mềm phù hợp và mức vá lỗi có thể được duy trì trên bất kỳ số lượng máy trạm nào.
• Có, bất kỳ "sự cố" nào cũng có thể xuất hiện trong môi trường thử nghiệm tự động và / hoặc QA / UAT.
• Nhiều nhà phát triển DB không dễ sao lưu, nhưng cũng không phải là không thể. Nếu sử dụng Cấu hình chuyển vùng, thì các tệp dữ liệu trong thư mục "Cài đặt cục bộ" của mỗi Người dùng Windows có thể dễ dàng sao lưu hơn. Hoặc ít nhất nó có thể được kịch bản bởi CNTT để lấy các tệp từ tất cả các máy trạm dev, tương tự như cách chúng sẽ đảm bảo rằng tất cả đều được vá đúng cách.

NHƯNG, như với hầu hết mọi thứ khác, nó thực sự đi vào bối cảnh của tình huống.

Một lợi ích của việc có các DB phát triển riêng biệt là các dự án khác nhau có thể được thực hiện đồng thời mà không ảnh hưởng lẫn nhau. (Tất nhiên, đây có thể là lợi ích duy nhất.)

TUY NHIÊN, có nhiều vấn đề cần xem xét:

• Quy mô của nhóm là bao nhiêu và có bao nhiêu người đang làm việc trong bất kỳ dự án cụ thể nào? Càng nhiều người bạn làm việc trong một dự án, bạn càng cần một máy chủ phát triển chia sẻ / tập trung để mọi người có được tất cả các thay đổi.

• Đối chiếu khôn ngoan, SQL Server Express LocalDB có một sắc thái / hạn chế / giới hạn đặc biệt khó chịu:

  Đối chiếu đối tượng cho LocalDB được đặt thành SQL_Latin1_General_CP1_CI_AS và không thể thay đổi. Đối chiếu mức cơ sở dữ liệu, mức cột và mức biểu thức được hỗ trợ bình thường. Cơ sở dữ liệu có chứa tuân theo các quy tắc đối chiếu siêu dữ liệu và tempdb được xác định bởi Thu thập cơ sở dữ liệu có chứa .

  Collation cấp độ trường hợp không chỉ ảnh hưởng tempdb(nghĩa là độ phân giải tên đối tượng trong phạm vi db và đối chiếu mặc định cho các bảng tạm thời nhưng không phải là biến bảng), mà còn cả tên biến / tên tham số cục bộ và gototên nhãn. Do đó, nếu các máy chủ Sản xuất của bạn có Đối chiếu cấp độ đối tượng khác SQL_Latin1_General_CP1_CI_AS, thì LocalDB không phải là một lựa chọn tốt.

• Bạn đang sử dụng các tính năng Enterprise Edition? Nếu đó chỉ là vấn đề khi thực hiện Rebu Index Index, thì điều đó có lẽ không thành vấn đề. Nhưng nếu bạn đang sử dụng một cái gì đó như Phân vùng bảng, thì LocalDB không phải là một lựa chọn tốt.

• Có lẽ vấn đề lớn nhất là phạm vi gia tăng chung của các vấn đề tiềm ẩn phát sinh từ bất kỳ sự chênh lệch môi trường nào (cấp độ hệ điều hành, cấp độ bản vá phần mềm, cấu hình cá thể, cấu hình DB, v.v.) có thể dẫn đến lỗi. Mặc dù chúng tôi đã chấp nhận (theo nghĩa chung) rằng kiểm tra tự động / QA / UAT sẽ tìm thấy những vấn đề này, điều đó không được đảm bảo ! Cho rằng con người mắc lỗi và con người cần phải đưa ra tất cả các thử nghiệm sẽ kiểm tra tất cả các đường dẫn mã và tất cả các biến thể của dữ liệu (loại, kích thước, v.v.), rất có thể là bất kỳ số lượng kịch bản nào sẽ không xảy rađược kiểm tra và một lỗi có thể khắc phục và không được chú ý cho đến khi khách hàng tìm thấy nó trong Sản xuất. Dù sao thì điều này cũng xảy ra, nhưng cơ hội sẽ tăng lên khi sử dụng LocalDB để mỗi nhà phát triển có thể có DB riêng của họ.

Những gì nó thực sự đi xuống là: lý do thuyết phục cho việc sử dụng nó trong môi trường nhóm là gì? Trong các công việc khác nhau, tôi luôn làm việc trong các nhóm có các Nhà phát triển ứng dụng và Kỹ sư cơ sở dữ liệu, và trong khi các Nhà phát triển ứng dụng đôi khi chế nhạo một quy trình được lưu trữ chỉ để thực hiện nhanh hơn (không đủ DBE của chúng tôi), các DBE đã làm hầu hết Lập trình DB, bao gồm kiểm tra (tức là sửa) bất kỳ mã nào mà App Devs đã viết. Việc sử dụng LocalDB sẽ khiến việc làm việc trong một nhóm trở nên khó khăn hơn nhiều. Và trong khi sử dụng SQL Server Express (hoặc thậm chí là Phiên bản dành cho nhà phát triển) để có các phiên bản cá nhân trên mỗi máy trạm dev có thể truy cập từ xa - giúp cộng tác dễ dàng hơn - thực sự không cần phải có mức độ cô lập như vậy vì hiếm khi xảy ra có những thay đổi DB cho một dự án tác động tiêu cực đến một dự án khác.

Tất nhiên, những người trong chúng tôi là Kỹ sư cơ sở dữ liệu (DBE) đã có các bản cài đặt cục bộ của Phiên bản Express và / hoặc Phiên bản dành cho nhà phát triển. Nhưng, đó là để thực hiện kiểm tra yêu cầu kiểm soát nhiều hơn đối với cấu hình / bảo mật ở mức cá thể, v.v. hơn mức có thể được cho phép trên một máy chủ dùng chung. Và tôi thỉnh thoảng sử dụng (các) ví dụ cục bộ, nhưng không thường xuyên lắm. Nhưng đối với các dự án cá nhân của tôi, tôi yêu LocalDB và sử dụng nó khá thường xuyên.