2010-07-27 18 views
7

Giả sử tôi có bàn sau trong cơ sở dữ liệu của tôi:Có tệ khi sử dụng các mối quan hệ thừa không?

tables http://www.freeimagehosting.net/uploads/a5ef036857.png

Bây giờ tất cả các truy vấn của tôi phụ thuộc vào bảng Công ty. Có thực tiễn không tốt để cung cấp cho mọi bảng khác một mối quan hệ (thừa) cho bảng Công ty để đơn giản hóa các truy vấn sql của tôi không?

Chỉnh sửa 1: Bối cảnh là vấn đề về sử dụng với khung. Xem Django: limiting model data.

Chỉnh sửa 2: Không có bộ phận nào thay đổi công ty của anh ấy.

Chỉnh sửa 3: Tôi không viết truy vấn mysql. Tôi sử dụng một lớp trừu tượng (django).

+0

Từ "quan hệ" không có nghĩa là ý của bạn là ý nghĩa của nó. Quan hệ * * trong mô hình cơ sở dữ liệu quan hệ tương ứng với hầu hết mọi người gọi một bảng. Nó không liên quan gì đến mối quan hệ giữa dữ liệu trong các bảng khác nhau. – sqlvogel

+0

Vâng, bạn nói đúng. Tôi đã sửa nó. – svenwltr

+0

@SvenWalter vui lòng cập nhật câu hỏi bằng bảng trong khối mã ('

') vì tệp hình ảnh bên ngoài không còn khả dụng nữa. Tôi chia sẻ nỗi đau khi không có các bảng thích hợp trong SE (các nhà phát triển khó có thể làm cho nó có sẵn), nhưng ít nhất chúng ta có thể mô phỏng chúng bằng các khối mã thay vì dựa vào các công cụ bên ngoài. –
                        
                            
    ADTC
                                
                            
                        
                    

Trả lời

7

Thực tiễn không tốt vì dữ liệu dư thừa của bạn phải được cập nhật độc lập và do đó dư thừa. Một quá trình đầy tiềm năng cho lỗi. (Ngay cả xếp tầng tự động cũng phải được chỉ định và duy trì riêng)

Bằng cách giới thiệu mối quan hệ này, bạn sẽ không chuẩn hóa một cách hiệu quả cơ sở dữ liệu của mình. Việc không chuẩn hóa đôi khi là cần thiết vì lợi ích của hiệu năng nhưng từ câu hỏi của bạn có vẻ như bạn chỉ đơn giản hóa SQL của bạn.

Sử dụng cơ chế khác để trừu tượng sự phức tạp của cơ sở dữ liệu của bạn: xem, lưu Procs, UDFs

+0

Nhiều RDBM có tầng cập nhật. Thay đổi ID công ty trong bảng công ty sẽ xếp vào tất cả các bảng tham chiếu đến nó. – siride

+1

siride: Đó là một điểm tốt nhưng duy trì khả năng hoạt động của các liên kết của bạn vẫn là một bước bảo trì bổ sung mà phải được thực hiện và phải được thực hiện một cách chính xác. Đơn giản hơn trong cuốn sách của tôi. Gắn bó với chìa khóa nước ngoài của bạn và sống với sự tham gia thêm trong các truy vấn của bạn. –

+0

Tôi thấy đó là một ý tưởng tồi. Cảm ơn sự giúp đỡ của bạn ... Tôi phải tìm một giải pháp khác. – svenwltr

4

Thực tiễn không tốt là cung cấp cho mọi bảng khác một mối quan hệ (dư thừa) vào bảng Công ty để đơn giản hóa các truy vấn sql của tôi?

Vâng, hoàn toàn, vì nó có nghĩa là cập nhật mỗi mối quan hệ không cần thiết khi bạn cập nhật các quan hệ khách hàng cho công ty hoặc phần cho công ty - và nếu bạn bỏ lỡ bất kỳ bản cập nhật như vậy, bây giờ bạn có một cơ sở dữ liệu đầy đủ các dữ liệu không cần thiết. Đó là một sự không chuẩn hóa xấu.


Nếu điểm của bạn là đơn giản hóa SQL, hãy xem xét sử dụng chế độ xem để "mang theo" dữ liệu gốc. Dưới đây là chế độ xem hợp đồng company_id thành hợp đồng, bằng cách tham gia thông qua khách hàng:

create view contract_customer as 
select 
    a.*, 
    b.contract_id, b.company_id 
from 
    contract a 
    join customer b on (a.customer_id = b.customer_id); 

Tham gia này rất đơn giản, nhưng tại sao lại lặp đi lặp lại? Viết nó một lần, và sau đó sử dụng quan điểm trong các truy vấn khác.

Nhiều (nhưng không phải tất cả) RDBMS thậm chí có thể tối ưu hóa tham gia nếu bạn không đặt bất kỳ cột nào từ khách hàng trong danh sách lựa chọn hoặc mệnh đề của truy vấn dựa trên chế độ xem, miễn là bạn thực hiện contract.customer_id có ràng buộc toàn vẹn tham chiếu khóa ngoài trên customer.customer_id. (Trong trường hợp không có ràng buộc như vậy, không thể bỏ qua phép nối, vì nó sẽ có thể cho một contract.customer_id tồn tại mà không tồn tại trong khách hàng. Vì bạn sẽ không bao giờ muốn rằng, bạn sẽ thêm ràng buộc khóa ngoài.)

Sử dụng chế độ xem đạt được những gì bạn muốn, mà không cần phải cập nhật bảng con, mà không cần làm cho hàng con rộng hơn bằng cách thêm cột dư thừa (và điều này thực sự bắt đầu quan trọng khi bạn có nhiều hàng, vì hàng càng rộng, hàng càng ít có thể vừa với bộ nhớ cùng một lúc), và quan trọng nhất, không có khả năng dữ liệu không nhất quán khi phụ huynh được cập nhật nhưng các con thì không.

2

Nếu bạn có nghĩa là thêm một cột Công ty để mỗi bảng, đó là một ý tưởng tồi. Nó sẽ làm tăng tiềm năng cho các vấn đề toàn vẹn dữ liệu (tức là nó được thay đổi trong một bảng nhưng không được thay đổi trong 6 bảng khác).

-1

Điều đó phụ thuộc vào các yêu cầu chức năng của bạn cho 'Hiệu suất'. Ứng dụng của bạn có xử lý được nhu cầu lớn không? Đơn giản hóa JOINS tự hào về hiệu suất. Bên cạnh phần cứng là rẻ và thời gian quay vòng là quan trọng. sâu

Bạn càng đi theo các hình thức bình thường cơ sở dữ liệu - giúp bạn tiết kiệm không gian nhưng nặng về tính toán

+0

YOu sẽ phải có cơ sở dữ liệu khổng lồ trước khi tham gia đang gây ra vấn đề về hiệu suất nếu bạn lập chỉ mục chính xác. Điều kỳ lạ là những người mà tôi biết ai quản lý cơ sở dữ liệu với hàng tỉ tỷ hồ sơ vẫn sử dụng các phép nối nhưng đó là bởi vì các nhà thiết kế cơ sở dữ liệu của các loại hệ thống đó đều có thẩm quyền. – HLGEM

4

Nếu bạn thực sự cần phải đơn giản hóa mọi thứ, đây là nơi mà một View (hoặc nhiều lượt xem) sẽ có ích.

Có một cột cho công ty trong nhân viên của bạn xem sẽ không được chuẩn hóa kém, cung cấp cột có nguồn gốc từ phần tham gia.

1

Tôi muốn nói không trong trường hợp của OP, nhưng đôi khi nó hữu ích (giống như goto;).

Một giai thoại:

Tôi đang làm việc với một cơ sở dữ liệu mà hầu hết bảng có một trỏ chính nước ngoài vào một bảng gốc cho các tài khoản. Số tài khoản nằm ngoài cơ sở dữ liệu và không được phép thay đổi sau khi được phát hành. Vì vậy, không có nguy cơ thay đổi số tài khoản và không cập nhật tất cả các tham chiếu trong DB. Tôi cũng thấy rằng nó cũng dễ dàng hơn để lấy dữ liệu từ các bảng được khóa bằng số tài khoản thay vì phải làm phức tạp và tốn kém khi gia nhập hệ thống phân cấp để đến bảng tài khoản gốc. Nhưng trong trường hợp của tôi, chúng tôi không có nhiều khóa ngoại như một định danh bên ngoài (nghĩa là thế giới thực), vì vậy nó không hoàn toàn giống với tình hình của OP và có vẻ phù hợp với một ngoại lệ.

5

Điều bạn đang hỏi là liệu có vi phạm Biểu mẫu thông thường thứ ba trong thiết kế của bạn hay không. Làm như vậy không phải là một cái gì đó để được thực hiện mà không có lý do chính đáng bởi vì bằng cách tạo ra dự phòng bạn tạo ra khả năng cho các lỗi và mâu thuẫn trong dữ liệu của bạn. Ngoài ra, "đơn giản hóa" mô hình với dữ liệu dự phòng để hỗ trợ một số hoạt động có khả năng làm phức tạp các hoạt động khác. Ngoài ra, các ràng buộc và logic truy cập dữ liệu khác có thể sẽ cần phải được nhân bản không cần thiết.

Các vấn đề liên quan