Tái cấu trúc hoặc nâng cấp cơ sở dữ liệu để xử lý các tính năng mới

Một số câu trả lời cho câu hỏi lược đồ cơ sở dữ liệu , đã đề xuất một bảng bổ sung để bình thường hóa cơ sở dữ liệu cho một tính năng không phải là một phần của các yêu cầu hiện tại (Bảng UserDepidor để cho phép mối quan hệ nhiều-nhiều giữa nhân viên / người dùng và các bộ phận khác nhau mà họ có thể thuộc về.).

Không chống lại bình thường hóa. Có vẻ như khi nói đến thiết kế cơ sở dữ liệu, có một sự thúc đẩy mạnh mẽ để bao gồm các tính năng mà họ 'chắc chắn' sẽ có ai đó muốn trong tương lai. Có quá khó để thêm bảng / trường vào cơ sở dữ liệu để chứa các tính năng mà có xu hướng kỹ sư quá mức không? Họ sẽ không được tái cấu trúc hoặc nâng cấp giống như phần còn lại của ứng dụng nếu cần? Làm lại mọi thứ không bao giờ thú vị, nhưng việc di chuyển dữ liệu từ một bảng sang một bảng mới có thể được thực hiện. Chỉ không chắc chắn dòng suy nghĩ này sẽ kết thúc ở đâu.

Chỉnh sửa: Có quá nhiều ác cảm với điều này, tôi tự hỏi có bao nhiêu dự án cuối cùng không thêm tính năng yêu cầu thay đổi cơ sở dữ liệu mạnh mẽ hoặc là các cách tiếp cận không chuẩn hóa được thực hiện như thêm trường DepartmentID2 thay vì bảng mới. Nhu cầu về nhiều bộ phận cho một nhân viên là một vấn đề tên miền phổ biến. Tôi chỉ không nhận thấy nhiều lược đồ cơ sở dữ liệu nằm rải rác với nhiều mối quan hệ nhiều-nhiều.

Có một cuốn sách viết về tái cấu trúc cơ sở dữ liệu. Giống như với tái cấu trúc mã, có những cách tiêu chuẩn để thực hiện tái cấu trúc cơ sở dữ liệu. Sự khác biệt duy nhất là khi thực hiện tái cấu trúc mã, bạn không phải xem xét trạng thái của đối tượng / mã, trong khi trong cơ sở dữ liệu bạn phải xem xét dữ liệu, vì thực tế việc mất dữ liệu không tốt cho người dùng (hoặc cho bất kỳ ai ).

Bạn có thể đọc thêm về tái cấu trúc cơ sở dữ liệu ở đây .

Tái cấu trúc mã rất dễ dàng - bạn chỉ cần thay đổi mã và chạy thử nghiệm hồi quy của mình.

Tái cấu trúc cơ sở dữ liệu rất khó - bạn phải di chuyển (một lượng rất lớn) dữ liệu xung quanh, đảm bảo không có dữ liệu nào bị bỏ, đảm bảo các ràng buộc được duy trì trong lược đồ mới. Và, nếu bạn có yêu cầu kiểm toán về dữ liệu, bạn đã có thể giải thích lý do tại sao nó được tổ chức khác nhau và có thể khớp dữ liệu tiền tái chế với dữ liệu sau tái cấu trúc. Ngoài ra, không có bản sao lưu cũ nào của bạn phù hợp với lược đồ mới, đây là một rủi ro khác.

Thứ đáng sợ.

Có một ranh giới tốt giữa việc dành nhiều thời gian cho kỹ thuật và đầu tư một chút thời gian của bạn để thêm các tính năng vừa đủ để giúp bạn tiết kiệm một lượng thời gian đáng kể trong tương lai.

Tôi nghĩ lý thuyết là nếu bạn bao gồm một bảng liên kết để hỗ trợ nhiều mối quan hệ giữa nhiều bảng, thì ngay cả khi thực sự chỉ có nhiều mối quan hệ tồn tại trong dữ liệu, mọi người sẽ viết SQL theo cách mà nếu có nhiều đến nhiều người được hỗ trợ mọi thứ sẽ "chỉ hoạt động".

Trong thực tế, tôi thường không thấy rằng điều này là đúng, nhưng tôi cho rằng SQL gần với những gì nó cần hơn để hỗ trợ nhiều người so với những gì nó có thể xảy ra.

Nhưng để cụ thể cho câu hỏi của bạn, thực sự có một nỗi đau khá lớn khi chuyển đổi một mối quan hệ từ 1 sang nhiều thành nhiều thành nhiều. Lý do là SQL không được thiết kế với cùng loại mục tiêu đóng gói của các đối tượng và hầu hết các truy vấn sử dụng nhiều bảng trên lớp cơ sở dữ liệu hơn mọi người sẽ cảm thấy thoải mái khi có một đối tượng trong lớp nghiệp vụ.

Do đó, việc thay đổi mối quan hệ nhiều thành nhiều sẽ ảnh hưởng đến mọi truy vấn liên quan đến 2 bảng gốc, thường là hiệu ứng xếp tầng rộng hơn nhiều so với sẽ xảy ra trên lớp doanh nghiệp. Vì vậy, mọi người đi đến chiều dài đáng kể để ngăn chặn điều này xảy ra.

IMHO điều này sẽ không cần thiết nếu chúng ta có ngôn ngữ tốt hơn SQL để chỉ định đại số quan hệ. Nếu có thể xây dựng một mảnh truy vấn SQL theo từng mảnh bởi các đối tượng không cần hiển thị cho mọi bảng trong truy vấn thì điều này sẽ không xảy ra. Những thứ như LINQ (với SQL hoặc thực thể) cố gắng giải quyết vấn đề này, nhưng đó là một giải pháp rất phức tạp và khó khăn để tối ưu hóa (và tôi đã từng đến các nhóm người dùng DBA nơi LINQ được đề cập và mỗi lần rên rỉ tập thể). Tôi mơ về một ngôn ngữ cơ sở dữ liệu được hỗ trợ toàn cầu với các hàm đại số quan hệ hạng nhất ...

Trong khi đó, vâng, bạn có thể cấu trúc lại từ 1 đến nhiều thành nhiều, nhưng nó có thể là rất nhiều công việc.

Tôi thường giải thích nó theo cách này với PHBs - mã là tường và mái nhà, cơ sở dữ liệu là nền tảng.

Di chuyển các bức tường và thay đổi mái nhà có thể được thực hiện. Thay đổi nền móng xung quanh đòi hỏi rất nhiều đào và xây dựng lại các bức tường và mái nhà.

Điều mà các nhà phát triển thiếu kinh nghiệm (và các giáo sư đại học) nói là "kỹ thuật quá mức" là điều mà các nhà phát triển có kinh nghiệm gọi là "bằng chứng trong tương lai". Mặc dù thông số kỹ thuật nói rằng bạn biết những gì có thể sẽ thay đổi trong ALM hoặc nơi các vấn đề về hiệu suất sẽ xảy ra để bạn muốn bắt đầu cấu trúc bảng của mình ngay.

Đưa ra các kịch bản cập nhật cho các máy chủ của khách hàng là một dự án không tầm thường và mỗi DBA của khách hàng đều khiến bạn muốn kiểm tra tất cả. Một số cột và bảng bổ sung không quá tệ.

Nguyên tắc chung là nếu một mối quan hệ là 1-1 nhưng có thể trong tương lai có nhiều nhiều sau đó làm cho nó một nhiều nhiều.

Nhân viên / bộ phận là một ví dụ cổ điển. Trong hầu hết các công ty nhỏ, điều này thực sự là một mối quan hệ một đến nhiều thời gian . Tuy nhiên, hầu như luôn luôn có một tình huống xảy ra với nhiều người - một trong số các kỹ sư của bạn chuyển sang quản lý, nhưng, vẫn chịu trách nhiệm hỗ trợ một sản phẩm mà anh ấy đã phát triển khi anh ấy làm kỹ sư, hoặc, một trong những người bán hàng của bạn chuyển đến Phát triển sản phẩm, nhưng, vì anh ta có mối quan hệ chặt chẽ với một khách hàng quan trọng nên anh ta vẫn là nhân viên bán hàng cho khách hàng đó.

Sẽ không tốn nhiều chi phí hơn nếu một đến nhiều người được triển khai như nhiều người - nhưng việc cấu trúc lại cơ sở dữ liệu và ứng dụng để hỗ trợ nhiều người rất tốn kém và gặp nhiều khó khăn.

Có hai cách để xem xét thiết kế phần mềm (và có thể nhiều thứ khác) - Một quan điểm chiến thuật hoặc một quan điểm chiến lược. Mỗi cái đều có ưu điểm và nhược điểm riêng.

Ngay cả khi sửa đổi phần mềm OO vẫn còn là một vấn đề khó khăn, không chỉ phần mã hóa là khó khăn, mà quá trình thúc đẩy thay đổi sản xuất trong môi trường khiếu nại (với tình trạng công nghệ hiện tại.) Là không thực tế đối với các hệ thống lớn được cho là làm việc 24/7.

Tôi tuân theo nguyên tắc của mình rằng: " Khi có thể, hãy thiết kế các tạo phẩm phần mềm dùng chung một cách chiến lược " - Điều này nghe có vẻ trái với nguyên tắc YAGNI theo một cách nào đó, tuy nhiên, đây là ý kiến ​​của tôi. Cách tiếp cận này đảm bảo ít làm việc lại với chi phí phức tạp và tài nguyên.

Trong trường hợp của bạn, các hoạt động cần thiết để thêm bảng nối mới sẽ bao gồm: thiết kế, phê duyệt thiết kế, thay đổi lược đồ, viết lại một số phương thức cho CRUD cho 3 bảng (ngoại trừ một số lần đọc), xây dựng chỉ mục, tạo GUI cho CRUD cho bảng mới, để cho phép người dùng chọn PK tạo, cập nhật bảng mới, v.v ... Ồ, và nhân tiện, đừng quên kiểm tra đơn vị, kiểm tra chấp nhận người dùng, kiểm tra hệ thống và quảng bá sản xuất.

Nếu điều này là không đủ, cơn ác mộng thực sự đến từ việc mất thông tin. Nếu bạn không có bảng kết nối để bắt đầu và bạn đã quyết định ghi lại những ngày xảy ra sự liên kết / tách biệt giữa nhân viên và bộ phận, bạn sẽ không thể tự động điền ngày trên bảng giao lộ. Bạn phải nhập chúng theo cách thủ công (nếu bạn có dữ liệu).

Vì vậy, tốt hơn là nên thấy trước điều này ngay từ đầu.

Như Matthew đã nói ở trên, tái cấu trúc / thay đổi cơ sở dữ liệu thường liên quan nhiều hơn so với phần mềm vì việc quản lý dữ liệu cũng cần được xem xét. Có các kỹ thuật có thể giúp, ví dụ như đảm bảo rằng bạn có một bộ kiểm tra đơn vị cơ sở dữ liệu phù hợp, tách riêng các ứng dụng khách khỏi lược đồ cơ sở của bạn bằng cách sử dụng 'DB API' - sprocs / view, v.v.