Bạn có thể có 2 bảng với cấu trúc giống hệt nhau trong một lược đồ DB tốt không?

Question

2 bảng:
- xem
- tải

cấu trúc giống hệt:
item_id, user_id, thời gian

Tôi có nên lo lắng?

Answer 1

Tôi không nghĩ rằng có vấn đề.

Khi thiết kế DB, có nhiều thông số khác nhau và một số (ví dụ: hiệu suất) có thể được ưu tiên.

Trường hợp tại điểm: ngay cả khi cấu trúc (và tôi giả sử lập chỉ mục) giống nhau, có thể "lượt xem" có nhiều bản ghi hơn và sẽ được truy cập thường xuyên hơn. Điều này một mình có thể là một lý do tốt để không phải gánh nặng nó với các hồ sơ từ các tải xuống.

Ngoài ra, thực tế là chúng hiện diện không có nghĩa là chúng sẽ ở trong tương lai: lượt xem và lượt tải xuống khác nhau, sau cùng thì sớm hoặc muộn một hoặc cả hai có thể phát triển thêm một hoặc hai trường.

Answer 2

Các bảng này giống nhau NGAY nhưng có thể thay đổi giản đồ trong tương lai. Nếu chúng đại diện cho 2 khái niệm khác nhau thì tốt nhất là giữ chúng riêng biệt. Điều gì sẽ xảy ra nếu bạn muốn có một khóa ngoại từ một bảng khác đến bảng tải xuống nhưng không phải bảng xem, nếu chúng là cùng một bảng bạn không thể làm điều này.

Answer 3

Từ quan điểm mô hình hóa E/R, tôi không thấy vấn đề gì với điều đó, miễn là chúng đại diện cho hai thực thể ngữ nghĩa khác nhau.

Từ một điểm thực hiện xem, nó thực sự phụ thuộc vào cách bạn có kế hoạch để truy vấn dữ liệu:

• Nếu bạn có kế hoạch để truy vấn những bảng độc lập với nhau, giữ cho chúng tách được một lựa chọn tốt
• Nếu bạn có kế hoạch truy vấn các bảng đó với nhau (có thể với UNION của một hoạt động JOIN), bạn nên xem xét lưu trữ chúng trong một bảng đơn với cột phân biệt đối xử để phân biệt loại của chúng

Khi xem xét có hợp nhất chúng không oa bảng duy nhất bạn cũng nên đưa vào tài khoản các yếu tố khác như:

• Số lượng dữ liệu được lưu trữ trong mỗi bảng
• Tỷ lệ mà tại đó dữ liệu phát triển trong mỗi bảng
• Tỷ lệ của thao tác đọc/ghi thực hiện trên mỗi bảng

Answer 4

Tôi nghĩ câu trả lời phải là "nó phụ thuộc". Như người khác đã chỉ ra, nếu lược đồ của một hoặc cả hai bảng có khả năng phát triển thì không. Tôi có thể nghĩ về các trường hợp khác tốt (đơn giản hóa mô hình bảo mật bằng cách cho phép ứng dụng/người dùng truy cập vào một hoặc khác).

Có nói điều này, tôi làm việc với một DB kế thừa trong đó này là một vấn đề. Chúng tôi có nhiều bảng giống hệt nhau cho hóa đơn của khách hàng. Dữ liệu thực sự được di chuyển giữa các giai đoạn khác nhau trong vòng đời xử lý. Nó làm cho một mớ hỗn độn phức tạp khi cố gắng truy cập dữ liệu.Nó có thể dễ dàng được giải quyết bằng cờ trạng thái trong lược đồ gốc, nhưng bây giờ chúng ta có hơn 20 năm mã được viết dựa trên phiên bản nhiều bảng.

Câu trả lời ngắn: phụ thuộc vào lý do tại sao chúng là cùng một lược đồ :).

Answer 5

Chris Date và Dave McGoveran chính thức hóa "Principle of Orthogonal Design". Nói một cách khái quát nghĩa là trong thiết kế cơ sở dữ liệu, bạn nên tránh khả năng cho phép cùng một bộ dữ liệu trong hai relvars khác nhau. Mục đích là để tránh một số loại dự phòng và sự mơ hồ nhất định có thể xảy ra.

Có thể cho rằng không phải lúc nào cũng thực tế hoàn toàn để thực hiện điều đó và không nhất thiết phải cắt chính xác khi nguyên tắc bị hỏng. Tuy nhiên, tôi nghĩ đó là quy tắc hướng dẫn tốt, nếu chỉ vì nó tránh được vấn đề logic trùng lặp trong mã truy cập dữ liệu hoặc các ràng buộc, tức là nguyên tắc DRY tốt. Tránh có các bảng có ý nghĩa trùng lặp tiềm ẩn trừ khi có một số ràng buộc cơ sở dữ liệu ngăn cản sự trùng lặp giữa chúng.

Answer 6

Tùy thuộc vào ngữ cảnh - số View và số Download là gì? Có phải là Download ngụ ý một số View (cách tải xuống khác) không?

Đó là có thể mà bạn có các khái niệm rõ ràng, riêng biệt ở đó - nhưng đó là mùi tôi muốn điều tra thêm. Có vẻ như một lượt xem và lượt tải xuống có liên quan bằng cách nào đó, nhưng mô hình của bạn không hiển thị bất kỳ thứ gì.

Answer 7

Bạn có nói rằng cả hai bảng đều có khóa chính 'item_id'? Trong trường hợp này, các trường có cùng tên, nhưng không có cùng ý nghĩa. Một là 'view_id' và cái kia là 'download_id'. Bạn nên đổi tên các trường của bạn do đó để tránh loại hiểu lầm này.