Nhiều cột so với vài bảng - hiệu suất khôn ngoan

Có, tôi biết rằng chuẩn hóa dữ liệu nên là ưu tiên của tôi (vì nó là như vậy).

1. Tôi đã có một bảng với 65 cột lưu trữ dữ liệu với xe cột: used_vehicle, color, doors, mileage, pricevà vân vân, trong tổng số 65.
2. Bây giờ, tôi có thể chia đó và có một Vehiclebảng, VehicleInterior, VehicleExterior, VehicleTechnical, VehicleExtra(tất cả one-to-one với chính Vehiclebảng).

Giả sử tôi sẽ có khoảng 5 triệu hàng (xe).

Bật SELECTvới một WHEREmệnh đề: Hiệu suất sẽ được tìm kiếm tốt hơn (cả hai trường hợp được lập chỉ mục ít nhất là trên IDs):

1. Vehicle bảng có 65 cột hoặc
2. Vehiclebảng với JOINSbốn bảng khác (tất cả có 5 triệu hàng) để trả về tất cả dữ liệu liên quan đến Vehicle?

(Theo công cụ cơ sở dữ liệu, hãy xem xét PostgreSQL và / hoặc MySQL).

Thực sự đánh giá cao bất kỳ hiểu biết chi tiết bạn có thể có từ kinh nghiệm trước đây của bạn?

Giả sử chúng ta đang nói về mối quan hệ 1: 1 giữa tất cả các bảng.

Lưu trữ tổng thể thực tế luôn rẻ hơn (thực chất) với một bảng thay vì nhiều bảng trong mối quan hệ 1: 1. Mỗi hàng có 28 byte trên không, cộng thêm một vài byte nữa cho phần đệm thêm. Và bạn cần lưu trữ cột PK với mỗi bảng. Và có một chỉ mục (dự phòng) riêng biệt trên mỗi cột này ... Kích thước không quan trọng đối với hiệu suất.

Điều này thậm chí đúng nếu nhiều cột là NULL trong hầu hết các hàng vì lưu trữ NULL rất rẻ :

• Cấu hình PostgreSQL để đọc hiệu suất

Trong khi truy xuất tất cả các cột, một bảng duy nhất nhanh hơn đáng kể so với 5 bảng được nối với nhau. Nó cũng đơn giản hơn nhiều . Năm bảng có thể khó tham gia nếu không phải tất cả các hàng đều có trong tất cả các bảng. Với các WHEREđiều kiện nhắm mục tiêu vào một bảng duy nhất, thật dễ dàng để nối thêm các bảng khác LEFT JOIN. Không tầm thường nếu bạn có các vị từ trên nhiều bảng ...

Phân vùng dọc vẫn có thể cải thiện hiệu suất của các truy vấn nhất định. Ví dụ: nếu 90% truy vấn của bạn truy xuất cùng 5 cột trong số 65 cột có sẵn, thì điều này sẽ nhanh hơn với một bảng chỉ giữ 5 cột này.

• Những gì được lấy từ đĩa trong một truy vấn? (câu trả lời của tôi)

OTOH, bạn có thể có thể phục vụ cho các truy vấn như vậy trên một vài cột được chọn với chỉ mục "bao phủ" cho phép quét chỉ mục .

Một ứng cử viên khác cho phân vùng dọc: Nếu bạn có nhiều cập nhật chỉ trên một vài cột, trong khi phần còn lại hầu như không thay đổi. Có thể rẻ hơn đáng kể để phân chia các hàng trong trường hợp như vậy, vì Postgres viết một phiên bản hàng mới cho mỗi bản cập nhật. Có các trường hợp ngoại lệ cho các giá trị lớn được lưu trữ ngoài luồng ("TOASTed"). Thêm chi tiết:

• Những gì được lấy từ đĩa trong một truy vấn? (Câu trả lời của Daniel)
• Cập nhật tất cả các cột từ bảng khác

Nó thực sự phụ thuộc vào tình hình hoàn chỉnh. Nếu nghi ngờ, hãy đi với giải pháp đơn giản là có một bảng duy nhất, đặc biệt nếu nó mô tả đúng thực tế: Trong ví dụ của bạn, đó là tất cả các thuộc tính của một chiếc xe hơi và có ý nghĩa với nhau.

Một lựa chọn trên một bảng duy nhất sẽ luôn luôn nhanh hơn. Ngay sau khi bạn đã tìm thấy chiếc xe của bạn, bạn đã có tất cả các chi tiết.

Tuy nhiên, bạn mất hiệu quả của bình thường hóa. Ví dụ: nếu 1 xe có nhiều mẫu với các tùy chọn khác nhau.

Đây có phải là một db tham khảo của tất cả các xe? Hoặc một danh sách các xe cũ? Sẽ có nhiều ví dụ về cùng một kiểu / mô hình với cùng các tùy chọn?

Chỉnh sửa: tôi nên đủ điều kiện câu trả lời của mình là rdbms chung chứ không phải là postgres cụ thể. Tôi trì hoãn câu trả lời chi tiết của @ Erwin cụ thể cho postgres