Đó có phải là công việc của các lập trình viên để thiết kế cơ sở dữ liệu?

Tôi đã là một lập trình viên trong sáu năm qua. Trong suốt sự nghiệp của mình, tôi đã làm việc trên nhiều ứng dụng web.

Hầu hết thời gian, khi cần một cơ sở dữ liệu, nó được trao cho chúng tôi (các lập trình viên) hoặc chúng tôi có một số cơ sở dữ liệu kế thừa để làm việc. Nếu không, chúng tôi phải tự tạo và thiết kế cơ sở dữ liệu không khó lắm.

Nhưng chúng ta, với tư cách là lập trình viên, có nghĩa vụ phải tạo toàn bộ cơ sở dữ liệu từ đầu khi chúng ta phải xây dựng ứng dụng mới trong đó dữ liệu rất quan trọng và có yêu cầu lộn xộn với mô hình dữ liệu phức tạp?

Có phải đó là lợi ích tốt nhất của ứng dụng và công ty để thực hiện nó bởi một chuyên gia?

Tôi không cố chạy trốn khỏi việc thiết kế cơ sở dữ liệu, nhưng đó là một điều rất quan trọng để làm đúng.

Trước hết, đó là công việc của bạn nếu người quản lý dự án nói với bạn như vậy. Các công ty nhỏ hơn thường không có chuyên gia DB toàn thời gian. Dù sao (và không nên) có sự phân biệt rõ ràng giữa các nhà phát triển và chuyên gia DB - bất kỳ nhà phát triển giỏi nào cũng sẽ có kiến ​​thức đáng kể về DB và bất kỳ DBA giỏi nào cũng sẽ biết cách viết mã, ít nhất là bằng ngôn ngữ của DB cho các thủ tục được lưu trữ .

Mặc dù thiết kế DB là một phần khá trung tâm của một ứng dụng, nhưng "đúng" không quan trọng hơn các phần trung tâm khác mà nhiều mã khác sẽ phụ thuộc vào.

Và cũng giống như mã, ý tưởng bạn khiến một số siêu chuyên gia ngồi xuống và suy nghĩ kỹ trong một tuần và sau đó viết ra thiết kế hoàn hảo sẽ không bao giờ cần thay đổi là một ảo ảnh. Thiết kế DB có thể và sẽ thay đổi khi ứng dụng đang được phát triển.

Do đó, thực sự có lợi khi có DB được thiết kế bởi một lập trình viên (người hiểu rõ về DB), bởi vì sau đó bạn có một người biết cả hai mặt. Điều đó chắc chắn tốt hơn so với việc ai đó chỉ hiểu DB và không liên quan gì đến phần còn lại của công việc phát triển.

Nó là phổ biến cho các lập trình viên để làm cho cơ sở dữ liệu. Rất phổ biến. Thật không may, nhiều lập trình viên không có kinh nghiệm với DB. Họ không hiểu làm thế nào để báo cáo chống lại dữ liệu lớn, các khái niệm về siêu dữ liệu, lược đồ sao, v.v. Một số thậm chí không hiểu những điều cơ bản của chuẩn hóa.

Nếu một người đàn ông có kỹ năng làm mọi thứ ở cấp độ chuyên gia thì nó tạo ra một sản phẩm rất tốt. Một đội quân một người có thể làm những gì một đội 10 người có thể làm trong một phần nhỏ thời gian với chất lượng gấp 1000 lần. Không phải là một cường điệu.

Đó là lợi ích tốt nhất cho lập trình viên để làm điều đó (ít người hơn), giả sử lập trình viên biết những gì anh ta đang làm. Tất nhiên có hàng ngàn thất bại để chỉ vào quá.

Đó là một câu hỏi thú vị - có một lập luận mạnh mẽ rằng hầu hết các nhà phát triển đàng hoàng nên hiểu cách cấu trúc đúng cơ sở dữ liệu quan hệ, nghĩa là họ phải có khả năng tạo ra một lược đồ chuẩn hóa và - dựa trên kinh nghiệm và các mẫu chung - để hợp lý quyết định về cách dữ liệu nên được cấu trúc lưu trữ (đối với tôi chủ yếu là hiển nhiên, nhưng tôi biết rằng không phải ai cũng nhìn thấy nó theo cách đó).

Hơn nữa, nếu bạn nhìn vào Entity Framework Code-first, điều đó cho thấy rằng cùng một suy nghĩ về việc xây dựng một mô hình dữ liệu cấp thấp sẽ tạo ra một lược đồ hợp lý - hoặc ít nhất là gợi ý về một.

Vì vậy, tôi không đặc biệt nghĩ rằng bạn cần một chuyên gia cơ sở dữ liệu để thiết kế một lược đồ cơ sở dữ liệu - ít nhất là không phải cho các cơ sở dữ liệu vừa và nhỏ (đó là những điều tôi đã làm việc).

Vấn đề là việc thiết kế một lược đồ tốt (hoặc ít nhất là đầy đủ) không phải là toàn bộ câu chuyện - đặc biệt là nếu cơ sở dữ liệu phải mở rộng quy mô. Dường như với tôi rằng "giá trị gia tăng" do DBA mang lại là trong việc lấy những thứ khác ngoài lược đồ cơ bản - lập chỉ mục, cấu hình lưu trữ, bảo trì cơ sở dữ liệu (giữ kích thước tệp trong kiểm tra, xây dựng lại chỉ mục, v.v.), thông minh hơn với người dùng và vai trò và vân vân.

Một lập trình viên giỏi sẽ mang đến một danh mục kỹ năng đa dạng - nên nhiều hơn một bộ mã hóa [chèn ngôn ngữ lựa chọn] và tôi sẽ bao gồm sự hiểu biết về cơ sở dữ liệu trong danh mục đầu tư đó.

Tôi nghĩ rằng khả năng thiết kế một cơ sở dữ liệu quan hệ hợp lý về cơ bản là cần thiết cho các lập trình viên không phải là thiếu niên.

Như đã nói, đặc biệt đối với các ứng dụng lớn, điều quan trọng là phải có cơ sở dữ liệu "đúng" ngay lần đầu tiên (lược đồ, lập chỉ mục, v.v.). Nếu công ty có quyền truy cập vào một DBA có kỹ năng, nhiệm vụ đó sẽ rơi vào đĩa của họ; nói chung họ sẽ có trình độ hơn. Có thể xem xét / thảo luận có khả năng với nhà phát triển chính, những người sẽ truy cập và làm việc với cơ sở dữ liệu ở phía khách hàng để không có bất ngờ nào. Nếu không có DBA, lập trình viên sẽ thiết kế cơ sở dữ liệu.

Tôi thấy hai câu hỏi ở đây:

• Có nên phát triển cơ sở dữ liệu mô hình logic kinh doanh?
• Tôi có nên biết làm thế nào để duy trì dữ liệu vào cơ sở dữ liệu?

Logic kinh doanh

• Logic kinh doanh không sống trong cơ sở dữ liệu. Đây là một mô hình khái niệm phải độc lập với các lớp khác trong hệ thống của bạn.

• Bạn luôn có thể thay thế một cơ sở dữ liệu bằng cơ sở dữ liệu khác hoặc thậm chí bạn có thể quyết định sử dụng giải pháp NoQuery để giải quyết các vấn đề hiệu suất tiềm năng.

• Các nhà phát triển cơ sở dữ liệu có thể được tham gia trong quá trình mô hình hóa, nhưng thông thường, điều này được thực hiện bởi những người có hiểu biết đầy đủ về một miền có vấn đề. Trong tổ chức của chúng tôi, điều này được thực hiện bởi các nhà phát triển phía máy chủ.

• Nhiều người nghĩ rằng cơ sở dữ liệu là một nền tảng của ứng dụng của bạn. Làm cho nền tảng kém, và hệ thống sẽ sụp đổ. Tôi không đồng ý với điều này. Tôi thấy cơ sở dữ liệu như một phương tiện lưu trữ có thể luôn luôn được thay thế.

Dữ liệu bền bỉ

• Bạn nên biết cách duy trì dữ liệu cho các phương tiện lưu trữ khác nhau, bao gồm các giải pháp SQL và NoQuery.

• Mức độ chuyên môn cần thiết sẽ thay đổi theo quy mô của hệ thống mà bạn đang làm việc.

• Các công ty nhỏ sẽ mong bạn có kiến ​​thức đó, khi các công ty lớn hơn thường thuê các chuyên gia để giải quyết các yêu cầu liên quan đến hiệu suất, khả năng mở rộng và bảo mật.

Để tóm tắt:

• Mô hình miền là một nền tảng của hệ thống của bạn, không phải là cơ sở dữ liệu.

• Nếu bạn làm việc cho một công ty nhỏ trong một dự án tương đối nhỏ, thì có lẽ bạn nên tự thiết kế cơ sở dữ liệu.

• Nếu bạn làm việc cho một công ty lớn trên một hệ thống doanh nghiệp, thì có lẽ sẽ có ý nghĩa hơn khi chuyển công việc cho các chuyên gia tên miền.