Có nên sử dụng Từ đồng nghĩa để tránh tạo bảng trùng lặp không?


13

Chúng tôi có 3 bản sao của cơ sở dữ liệu chính xác. Tất cả 3 cơ sở dữ liệu đều có một Usersbảng và Người dùng sẽ luôn tồn tại trong cả 3 cơ sở dữ liệu với cùng các cài đặt. Bất cứ khi nào chúng tôi muốn thêm hoặc chỉnh sửa Người dùng, chúng tôi phải cập nhật 3 cơ sở dữ liệu.

Sẽ là một ý tưởng tốt hơn để xóa Usersbảng khỏi cơ sở dữ liệu 2 và 3 và thay thế nó bằng một Synonymđiểm trỏ đến cơ sở dữ liệu 1?

Đây là ưu / nhược điểm tôi có thể nghĩ đến:

Ưu

  • Bảo trì dễ dàng hơn. Có thể cập nhật Người dùng ở một vị trí thay vì 3
  • Id người dùng sẽ khớp giữa các cơ sở dữ liệu (Quan trọng vì có rất nhiều ứng dụng bổ trợ dựa trên UserId)

Nhược điểm

  • Đừng nghĩ rằng đây là quy trình chuẩn, nên có thể gây nhầm lẫn
  • Người dùng sẽ phải có các cài đặt giống hệt nhau giữa các cơ sở dữ liệu
  • (Từ câu trả lời của gbn bên dưới) Nếu Cơ sở dữ liệu 1 bị hỏng, Cơ sở dữ liệu 2 và 3 cũng sẽ không khả dụng. Ngoài ra, có một vấn đề tiềm ẩn là dữ liệu không nhất quán trong trường hợp khôi phục

Đây là một tùy chọn tôi đang xem xét cho một vài bảng khác nhau có chứa Cài đặt giống hệt nhau giữa các cơ sở dữ liệu, không chỉ Usersbảng. Tôi đang sử dụng Người dùng trong ví dụ vì nó dễ hiểu.


3
Sẽ có ý nghĩa hơn khi có một kịch bản để đồng bộ hóa / hợp nhất sự khác biệt giữa chúng? Cá nhân tôi không thích làm 2 cơ sở dữ liệu phụ thuộc vào một phần ba vì một từ đồng nghĩa như thế này.
Thất vọngWithFormsDesigner

@FrustratedWithFormsDesigner Điều đó có vẻ như nhiều công việc hơn và thật khó để hợp nhất các thay đổi với các trường được tạo tự động như khóa chính.
Rachel

Nó phụ thuộc vào mức độ ưa thích mà bạn muốn nhận được. Nếu bạn muốn chia sẻ những thay đổi giữa chúng, thì có, nó có thể trở nên phức tạp. Nếu bạn muốn chỉ định một người là Master, thì đơn giản chỉ là vấn đề ghi đè nội dung của những người khác bằng nội dung của Master.
Thất vọngWithFormsDesigner

@FrustratedWithFormsDesigner Thật không may, ứng dụng là nguồn đóng và không có gì ngăn mọi người thêm hoặc chỉnh sửa người dùng trong bất kỳ Cơ sở dữ liệu nào. Tôi sẽ phải thực hiện các thay đổi hai chiều vì mọi người đều có khả năng thay đổi mật khẩu của riêng họ và hầu như tất cả các nhà quản lý đều có quyền truy cập vào quản lý người dùng để thêm / chỉnh sửa người dùng.
Rachel

Câu trả lời:


6

Tại sao bạn có 3 cơ sở dữ liệu với cùng một người dùng?

Điều gì xảy ra nếu một cơ sở dữ liệu đi xuống bây giờ?

Tôi đang hỏi những câu hỏi này bởi vì Con của cơ sở dữ liệu nguồn người dùng sẽ không sử dụng hai cơ sở dữ liệu kia có thể không phải là vấn đề lớn như âm thanh.

Ngoài ra, nếu cơ sở dữ liệu ngừng hoạt động, bạn sẽ gặp vấn đề về tính nhất quán nếu người dùng được sửa đổi trong hai DB khác trong khoảng thời gian đó. Tôi không nghĩ chúng ta có thể đưa ra lời khuyên tốt nhất mà không cần thêm ngữ cảnh.

Ngay bây giờ tôi sẽ tạo một cơ sở dữ liệu thứ tư cho người dùng, chỉ thực hiện các thay đổi ở đó và đồng bộ hóa trên các cơ sở dữ liệu khác. Bạn đã được phân phối - không chuẩn hóa bằng cách thay đổi về cơ bản cùng một dữ liệu ở ba nơi và có thể đã có vấn đề về tính nhất quán. Nếu khả năng chịu lỗi là quan trọng thì sơ đồ này vẫn đưa ra điều đó trong khi giải quyết vấn đề nhiều mục.

Tôi nghĩ rằng việc có cơ sở dữ liệu chỉ dành cho người dùng / cài đặt thứ tư này thay vì sử dụng một trong những cơ sở dữ liệu hiện có của bạn là một chiến lược tốt vì nó sẽ ít bị hỏng hơn vì nó không bị ràng buộc với các tài nguyên khác hoặc được sử dụng nhiều. Tôi thấy bây giờ bạn nói rằng bạn không thể làm điều này, nhưng tôi không rõ tại sao. Các ứng dụng trên cơ sở dữ liệu chính có hỗ trợ người dùng chỉnh sửa trực tiếp hay người dùng đang chỉnh sửa một chức năng hoàn toàn riêng biệt có thể được chỉ ra ở nơi khác?

Đúng, với ý tưởng "bảng người dùng chuẩn" này - cho dù bạn sử dụng từ đồng nghĩa hay đồng bộ hóa dữ liệu - bạn không thể sửa đổi người dùng trong DB người dùng xuống, nhưng điều đó có vẻ ổn với tôi. Khắc phục sự cố và đưa nó lên! Một nguồn, một nơi để chỉnh sửa, một điều cần sửa nếu bị hỏng. Với đồng bộ hóa, tất cả các cơ sở dữ liệu khác có bản sao tạm thời mà chúng có thể hoạt động nhưng không chỉnh sửa. Giảm thiểu sao chép dữ liệu trên các hệ thống là một mục tiêu tuyệt vời và hữu ích. Việc nhập cùng một dữ liệu vào ba vị trí là một vấn đề nghiêm trọng, vì vậy hãy làm bất cứ điều gì bạn có thể để loại bỏ điều đó.

Để giải quyết nhiều ý kiến ​​của bạn hơn, nếu ID người dùng của bạn khác với tất cả các ứng dụng của bạn, thì bạn nên nghiêm túc xem xét thời gian dự kiến ​​cho hai cơ sở dữ liệu mới của mình để đưa chúng đồng bộ với cơ sở dữ liệu chính (hỏi một câu hỏi riêng nếu bạn cần ý tưởng về cách thực hiện điều này, đó là khó khăn nhưng không thực sự khó khăn).

Nếu bạn phân tích nhu cầu kinh doanh của mình và thấy rằng cơ sở dữ liệu chính phải có dữ liệu người dùng thì không sao, bạn vẫn sử dụng nó dưới dạng chính tắc, sau đó chọn giữa các từ đồng nghĩa hoặc đồng bộ hóa để giải quyết thời gian không dự tính ảnh hưởng đến tất cả các cơ sở dữ liệu.

Thêm một Con sử dụng từ đồng nghĩa là bạn sẽ không còn có thể có FK thích hợp cho Người dùng trong mỗi cơ sở dữ liệu.


3

Có một "Con" bị thiếu

Khi khôi phục, có thể người dùng của bạn sẽ không tồn tại trong cơ sở dữ liệu đích (của từ đồng nghĩa). Giả sử nó bị hỏng và bạn phải khôi phục từ bản sao lưu.

Đó là, việc sử dụng các từ đồng nghĩa sẽ giả định tính toàn vẹn tham chiếu cơ sở dữ liệu không thể xảy ra trong cuộc sống thực.

Một hậu quả khác của điều này sẽ là người dùng không khớp khi bạn cố gắng phục hồi từ điều này. (bằng cách thêm người dùng sau khi khôi phục). Tuy nhiên, điều này không bao giờ nên được thừa nhận vì tính toàn vẹn tham chiếu cơ sở dữ liệu chéo mà tôi đã đề cập.

Vì vậy, đừng làm điều đó ...

Câu trả lời liên quan trên dba.se: Tiêu chí quyết định khi nào nên sử dụng lược đồ không phải dbo so với Cơ sở dữ liệu mới về "tính toàn vẹn tham chiếu cơ sở dữ liệu chéo" sau khi khôi phục


Điểm hay về khả năng mục tiêu không tồn tại, mặc dù tôi vẫn đang cố gắng tìm hiểu tại sao liên kết có liên quan đến câu hỏi này
Rachel

1
@Rachel: không, bảng mục tiêu có thể tồn tại nhưng dữ liệu có thể cũ hơn. Vì vậy, khi bạn khôi phục, bạn có một người dùng bị mất ... Liên kết là về "tính toàn vẹn tham chiếu cơ sở dữ liệu chéo"
gbn

2

Tùy thuộc vào nền tảng cơ sở dữ liệu của bạn, một tùy chọn khác là xóa các bảng trong cơ sở dữ liệu 2 và 3 và thay thế chúng bằng các khung nhìn cụ thể hóa của bảng trong cơ sở dữ liệu 1.

Ưu

  • Bảo trì dễ dàng hơn (Của dữ liệu)
  • Id phù hợp
  • Mất điện không ảnh hưởng đến các cơ sở dữ liệu khác (ít nhất là cho đến khi cần thay đổi)
  • Bất kỳ cơ sở dữ liệu có thể được sử dụng để phục hồi bảng.

Nhược điểm

  • Dữ liệu chỉ được cập nhật như lịch trình làm mới của bạn.
  • Nếu định nghĩa bảng thay đổi, các khung nhìn cụ thể hóa cũng có thể cần phải thay đổi.

Cũng lưu ý rằng tùy thuộc vào tần suất tra cứu, tần suất làm mới và tần suất thay đổi dữ liệu, điều này có thể hoặc không thể đưa ra nhiều tải hơn một giải pháp đồng nghĩa.


Cập nhật: FrustratedWithFormsDesigner về cơ bản là Chế độ xem được Vật chất hóa cho các nền tảng không thể thực hiện các chế độ xem được cụ thể hóa. Sử dụng tập lệnh, các bảng có thể được đồng bộ hóa định kỳ. Nếu một cơ sở dữ liệu được chỉ định là chủ thì tất cả các tập lệnh có thể thực hiện thay đổi dựa trên cơ sở dữ liệu đó. Điều này sẽ có tất cả những ưu và nhược điểm của một quan điểm cụ thể hóa; nó chỉ không thể tận dụng chức năng tích hợp.


1
Bạn không thể cụ thể hóa các chế độ xem (các chế độ xem được lập chỉ mục ở đây) cross-db trong SQL Server + chúng không cần được làm mới: chúng là "thời gian thực"
gbn

@gbn Bài viết của tôi đã được viết trước khi thẻ SQL Server được thêm vào.
Leigh Riffel

Tôi đã thêm thẻ dựa trên câu trả lời của bạn :)
Rachel

1

Tôi sẽ tạo DB thứ 4 lưu trữ Thông tin người dùng được chia sẻ. Tạo Synonymshoặc Viewstrong mỗi Dbs khác trỏ đến DB người dùng.

Cuối cùng, tôi sẽ tạo một bảng mở rộng (một bảng có mối quan hệ Một đối một với 'UserDB.Usertable') trong mỗi 3 dbs hiện có chứa dữ liệu người dùng cụ thể cho ứng dụng đó.


Chỉnh sửa: Dựa trên nhận xét bên dưới

Trong trường hợp đó, làm cho db đầu tiên hoạt động như bảng người dùng chính. Synonymsvà một bảng mở rộng trong mỗi Dbs khác.

Lưu ý quan trọng : Với phương pháp này, nếu ứng dụng đầu tiên của bạn bị hỏng, hai ứng dụng còn lại sẽ bị kéo xuống! Hãy chắc chắn rằng mọi người đều hiểu nhược điểm này.


Đáng buồn thay, đó không phải là một lựa chọn cho tôi. Nó sẽ là lựa chọn ưa thích của tôi nếu tôi đang thiết kế một cái gì đó từ đầu, nhưng trong trường hợp này tôi đang làm việc với một hệ thống có sẵn. Trong trường hợp của tôi, chúng tôi đã có Cơ sở dữ liệu 1 tồn tại trong nhiều năm và gần đây đã thêm Cơ sở dữ liệu 2 và 3.
Rachel

Tại sao có thể xóa các bảng và trỏ Từ đồng nghĩa với db đầu tiên mà không xóa một bảng mới?

Xin lỗi, chỉnh sửa nhận xét của tôi trước khi tôi nhìn thấy bạn. Cơ sở dữ liệu 1 đã tồn tại trong nhiều năm và được truy cập bởi nhiều ứng dụng bên ngoài. Tôi không chắc chắn về loại thiệt hại mà tôi gây ra bằng cách loại bỏ bảng đó. Cơ sở dữ liệu 2 và 3 mới hơn nên tôi nghĩ rằng tôi có thể thoát khỏi việc xóa bảng Người dùng (và các bảng cài đặt khác) và thay thế chúng bằng các từ đồng nghĩa
Rachel

Tôi thấy chỉnh sửa của bạn ... đó chính xác là những gì tôi đang cố gắng thực hiện nhưng câu hỏi của tôi là đây có phải là một ý tưởng tốt hay không, và nếu không, tại sao?
Rachel

Tốt rồi. Nếu bạn ổn, làm cho 2 ứng dụng tin tức hoàn toàn phụ thuộc vào ứng dụng đầu tiên.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.