Làm thế nào để giữ cho hai cơ sở dữ liệu với các lược đồ khác nhau được cập nhật

Question

Công ty chúng tôi có hệ thống cũ thực sự với thiết kế cơ sở dữ liệu xấu (không có khóa ngoài, cột với mảng PHP tuần tự, v.v.). .. một hệ thống từ một vết trầy xước với CSDL mới

chúng tôi muốn viết lại một hệ thống bằng phần Vì vậy, chúng tôi sẽ chia ứng dụng khối cũ đến nhiều cái nhỏ hơn

vấn đề là:. chúng tôi muốn có dữ liệu trực tiếp trong hai Cơ sở dữ liệu Lược đồ cũ và mới Tôi muốn hỏi bạn liệu có ai trong số các bạn biết thực hành tốt nhất về cách thực hiện điều này không.

Những gì chúng ta nghĩ về:

1. đồng bộ hóa dữ liệu không đồng bộ với hàng đợi thông điệp
2. làm cho một API REST trong hệ thống mới và làm cho ứng dụng di sản để sử dụng nó thay vì db gọi
3. một số loại sao chép bảng

Cảm ơn bạn rất nhiều

Answer 1

Tôi đã phải đối phó với một vấn đề tương tự trong quá khứ. Có một hệ thống không có hỗ trợ nhưng có người sử dụng nó bởi vì, Nó có một số tính năng (lỗ hổng bảo mật) cho phép họ một số chức năng nhất định. Tuy nhiên, họ cũng cần các chức năng mới.

Tôi đã chọn các bảng có liên quan đến hệ thống mới và tôi đã tạo một số trình kích hoạt để cập nhật chéo bảng, vì vậy khi tôi tạo đăng ký trên hệ thống cũ, trình kích hoạt đã tạo bản sao trong hệ thống mới và đảo ngược. Nếu bạn thiết kế hệ thống này đúng cách, bạn sẽ có cả hai hệ thống làm việc cùng một lúc trong thời gian thực.

Hạn chế là trong khi cả hai hệ thống đang chạy hệ thống sẽ trở nên chậm hơn vì bạn phải duy trì tính toàn vẹn của hai cơ sở dữ liệu trong mọi hoạt động.

Answer 2

Tôi sẽ bắt đầu bằng cách thêm lớp cơ sở dữ liệu để chấp nhận cuộc gọi API từ lớp doanh nghiệp, sau đó ghi vào cả lược đồ cũ và mới. Điều này thêm độ phức tạp lên phía trước, nhưng nó cho phép bạn đảm bảo rằng dữ liệu vẫn được đồng bộ hóa.

Điều này sẽ yêu cầu thay đổi hệ thống cũ để gọi API thay vì phát hành các câu lệnh SQL. Nếu họ không có tầm nhìn xa để làm điều đó ban đầu, bạn có thể không có khả năng để có cách tiếp cận của tôi. Nhưng, bạn nên làm điều đó trong tương lai.

Trình kích hoạt có thể có hoặc không hoạt động. Trong các phiên bản cũ của MySQL, có thể chỉ có một kích hoạt của một kiểu đã cho trên một bảng đã cho. Điều này buộc bạn gộp những thứ không liên quan vào một kích hoạt duy nhất.

Nhân rộng có thể giải quyết một số thay đổi - Công cụ, kiểu dữ liệu, v.v. Nhưng không thể tách một bảng thành hai. Hãy cẩn thận về sự nhân bản của Triggers và nơi Trigger có hiệu lực (giữa Master và Slave). Nói chung, một thói quen được lưu trữ phải được thực hiện trên Master, cho phép hiệu ứng được nhân rộng đến slave. Nhưng nó có thể là giá trị xem xét làm thế nào để có kích hoạt chạy trong Slave để thay thế. Hoặc các trình kích hoạt khác nhau trong hai máy chủ.

Một ý nghĩ khác là thực hiện chuyển đổi theo từng giai đoạn.Bằng cách lập kế hoạch cẩn thận về thay đổi lược đồ so với ứng dụng của trigger so với thay đổi mã so với lớp cơ sở dữ liệu, bạn có thể thực hiện chuyển đổi từng phần một, đôi khi không bị mất điện lớn để cập nhật mọi thứ cùng một lúc. Một ví dụ đơn giản: (1) thay đổi mã để tự động xử lý lược đồ mới hoặc cũ, (2) thay đổi lược đồ, (3) dọn sạch mã (loại bỏ xử lý lược đồ cũ).

Answer 3

Thực hiện di chuyển cơ sở dữ liệu có thể là một công việc tẻ nhạt khi xem xét độ phức tạp của dữ liệu và cấu trúc của các bảng, tất nhiên là có bất kỳ ràng buộc hoặc thiết kế phù hợp nào. Nhưng cho rằng ứng dụng cũ của bạn đã thực hiện công việc của mình - lượng dữ liệu có thể sử dụng bị hỏng sẽ là tối thiểu.

Đối với vấn đề đã nêu, tôi sẽ đề xuất tác vụ di chuyển db sẽ chuyển đổi tất cả dữ liệu cũ cũ sang biểu mẫu mới. Và phát triển ứng dụng mới. Những lợi thế được.

1) Không cần phải giữ 2 ứng dụng khác nhau.

2) Không cần phải thay đổi mã trong ứng dụng cũ - điều này có thể trở nên lộn xộn.

3) Di chuyển DB sẽ cho chúng ta cơ hội sửa bất kỳ dữ liệu hỏng nào (nếu cần).

Di chuyển DB có thể không thực tế trong tất cả các trường hợp nhưng nếu bạn có thể làm điều đó trong nỗ lực ít hơn so với thực hiện thay đổi đồng bộ hóa cơ sở dữ liệu, ứng dụng cũ của api mới - tôi khuyên bạn nên thực hiện.