Mở rộng lớp truy cập dữ liệu

9

Tình huống: Dba là một nhà thầu ngoại vi, người đã kiểm tra toàn bộ mã DAL trong TFS. Sẽ thật tuyệt khi nhà phát triển giao diện người dùng có thể thêm các cột và tinh chỉnh procs và whatnot, mà không phải phụ thuộc vào việc chờ đợi anh chàng này trả lời email của bạn để thực hiện công việc.

Câu hỏi: Điều gì sẽ là một giải pháp / quy trình được đề xuất cho phép phát triển nhanh / nhanh hơn, trong khi vẫn duy trì tính toàn vẹn dữ liệu cũng như tình yêu hòa bình và hạnh phúc giữa các đội?

— spaghetticowboy
nguồn

Tôi lo lắng ở đây về lý do tại sao bạn cần thêm một cột và những quy tắc kinh doanh nào được liên kết với cột này. Bạn có thể tìm cách xoay quanh nó và cuối cùng thêm cột nhưng nếu bạn sử dụng sai kiểu dữ liệu, cài đặt null, định nghĩa chỉ mục, điều tồi tệ hơn là nếu cột không nên thuộc về bảng hoặc nếu bạn thiếu một bảng giao nhau thì sao? Tôi nghĩ ai đó phải chịu trách nhiệm về tác động kinh doanh của việc xác định dữ liệu mới và cũng có người phải chịu trách nhiệm về tác động của thay đổi cơ sở dữ liệu đối với mã (trừ DBA). Hai vai trò có thể được chơi bởi cùng một người.

— NoChance

Yêu cầu DBA Để làm việc trong chi nhánh của mình. Đừng cho họ quyền thanh toán cho chi nhánh phát triển chính. Thay phiên tạo chi nhánh dev của riêng bạn và hợp nhất các thay đổi của bạn khi cần thiết.

— SoylentGray

11

Martin Fowler và Pramod Sadalage đã viết một bài viết xuất sắc về chủ đề này.

Mỗi nhà phát triển có cơ sở dữ liệu riêng của mình để thay đổi có thể được thực hiện. Những thay đổi này sau đó được truyền lại (dưới dạng thay đổi) cho DBA, người thực hiện chúng trong cơ sở dữ liệu chủ, vì vậy anh ta vẫn tham gia vào quá trình, dù sao anh ta cũng có thể biết rõ nhất về cấu trúc và nhu cầu của cơ sở dữ liệu. Tôi nghĩ đó là cách tiếp cận tốt nhất vì nó thỏa đáng cho tất cả những người tham gia vào quá trình và nó cũng rất nhanh nhẹn.

Bạn có thể thay đổi DAL theo cách tương tự. Chỉ cần thực hiện các thay đổi của bạn và cung cấp một bộ thay đổi cho DBA khi bạn nghĩ rằng bạn đã hoàn thành, để anh ta có thể xem xét và hợp nhất nó vào chủ của mình.

— Chim ưng
nguồn

1

oooh tôi thích ... đây là Q đầu tiên của tôi ở đây vì vậy tôi chưa thể upvote nhưng bạn chắc chắn có một câu hôn mê ... có lẽ / có lẽ câu trả lời cũng vậy, nhưng tôi muốn chờ một chút để xem người khác nói gì

— spaghetticowboy

Vấn đề với điều này là nhà phát triển thực hiện tất cả công việc của mình với giả định rằng dba sẽ chấp thuận.

— HLGEM

@ HLEGM: Theo kinh nghiệm của tôi, đây là trường hợp hiếm khi xảy ra, hầu hết các lần DBA sẽ phê duyệt hoặc chỉ thay đổi một chút. Vẫn tốt hơn là có những nhà phát triển nhàn rỗi ngồi xung quanh. Hơn nữa, nó có thể sẽ dẫn đến giải pháp tốt nhất nếu DBA và dev đều là những người hợp lý.

— Falcon

+1 để giải thích lý do tại sao đây là một bài viết xuất sắc thay vì chỉ đăng một liên kết.

— JeffO

@HLGEM - Tôi nghĩ rằng nó đòi hỏi cả hai bên phải biện minh cho những gì họ đang làm. DBA sẽ nhận được lợi ích của sự nghi ngờ trong các vấn đề db, nhưng cả hai phải trả lời cho người khác có quyết định cuối cùng.

— JeffO

3

Chà, khi tôi đang làm điều DBA, tôi đã biết khóa tất cả mọi thứ để các lập trình viên bẩn thỉu chết tiệt không thể có được mits của họ trên đó. Mọi người đều nghĩ rằng họ biết cách làm điều đó tốt hơn và họ "điều chỉnh" mọi thứ để giúp họ dễ dàng hơn và điều đó gây ra một mớ hỗn độn.

Một cách khác là mở nó ra và để các lập trình viên cận chiến một lúc, sau đó nhảy vào và áp đặt trật tự khi mọi thứ bắt đầu khép lại ... Điều này chắc chắn là "nhanh nhẹn" hơn, nhưng nó có thể một cơn ác mộng thực sự tùy thuộc vào những gì phải cắt bỏ hoặc thay đổi ... Các DBA thường hiểu rõ hơn về toàn bộ dự án và một số thay đổi có vẻ vô hại có thể là vấn đề.

Nếu anh ta trở thành người gác cổng duy nhất, anh ta cần phải có một thông số cố định hoặc có thể "bán" tầm nhìn của mình cho các nhà phát triển còn lại.

— Satanicpuppy
nguồn

chúng tôi khá là bẩn thỉu ... và đôi khi chúng tôi cũng khá thiếu kiên nhẫn và cần phải tự mình hoàn thành công việc

— spaghetticowboy

@spaghetti: Yea ... Có lẽ tôi tệ hơn hầu hết vì tôi đã làm rất nhiều công việc DBA, vì vậy tôi có gấp đôi "Tôi biết cách làm điều đó tốt hơn!" hơn hầu hết các lập trình viên. Tôi sẽ nói điều này: với cơ sở dữ liệu, việc lấy nó sớm hơn rất nhiều ... Nếu bạn tiếp tục bổ sung cho đến cuối dự án, điều đó gần như chắc chắn sẽ gây ra vấn đề.

— Satanicpuppy

3

Có một vấn đề lớn thay thế cho bất kỳ vấn đề nào khác:

Tại sao nhà thầu luôn có mã kiểm tra?

Tại sao anh ta được phép làm điều này? Không ai nên kiểm tra tệp trừ khi họ chủ động chỉnh sửa. Cần có một chính sách nhóm về kiểm tra.

Nhà thầu (dù muốn hay không) làm việc như một phần của nhóm và đôi khi các thành viên khác trong nhóm có thể cần thực hiện thay đổi. Đây là một vấn đề truyền thông. Thật không có cách tự động để khắc phục vấn đề giao tiếp này, thật không may.

— George Stocker
nguồn

1

Thay vì các lớp ngang, tôi thích làm việc trong các lớp trên silo.

Bằng cách đó, không ai / nhóm có thể chặn trong thời trang này.

Điều đó cũng có nghĩa là các nhà phát triển của bạn đa kỹ năng và có thể di chuyển xung quanh các tính năng dễ dàng hơn nhiều.

Tất nhiên, có những phần (thiết kế UI và thiết kế DB) có thể cần nhiều công việc đặc biệt hơn, nhưng bạn có ý tưởng.

— ozz
nguồn

1

Đơn giản, nếu bạn chưa có, bạn nên có 3 Môi trường:

Môi trương phat triển
Môi trường QA
Môi trường sản xuất

Môi trường phát triển nên được quản lý bởi các nhà phát triển của bạn.

Bạn cũng có thể muốn thêm một môi trường RC.

Một câu trả lời khác, Nếu không thể có nhiều môi trường, bạn có thể phát triển dựa trên kho lưu trữ bị chế giễu ... Bằng cách này, bạn xây dựng các mô hình của mình và sau đó nhà thầu của bạn có thể đáp ứng để làm cho các mô hình của bạn khớp với DB. Theo cách này thì tốt hơn vì nó giải phóng các nhà phát triển của bạn khỏi lo lắng về cơ sở dữ liệu.

— AJC
nguồn

1

OP đang nói về mã được kiểm tra. Môi trường khác nhau sẽ không có tác động.

— NotMe

1

Vấn đề của bạn dường như là một trong những nhân lực. Nó phù hợp và cần thiết cho tất cả các thay đổi cơ sở tiềm năng được phê duyệt bởi một chuyên gia cơ sở dữ liệu. Nếu người hiện tại không thể theo kịp công việc kịp thời, bạn cần nhiều chuyên gia cơ sở dữ liệu hơn.

— HLGEM
nguồn

+1: Đây cũng có thể là một nguyên nhân của vấn đề. Nhiều công ty có quá ít DBA.

— Falcon

1

Đây là một vấn đề quản lý nhiều như một kỹ thuật.

Chắc chắn có những lý do hợp lệ cho một DBA (bất kể tại chỗ hay tắt, nhà thầu hoặc nhân viên) để ngăn các nhà phát triển tránh thực hiện bất kỳ loại thay đổi cơ sở dữ liệu nào.

Tuy nhiên, vấn đề chính bạn xác định là một trong những vấn đề có sẵn. Người quản lý của bạn có biết rằng thời gian / tiền bạc bị lãng phí khi chờ đợi người này không? Nếu không, bạn có thể muốn đưa nó lên như thế nào mọi người đang ngồi xung quanh.

— Không phải tôi
nguồn