2008-12-08 18 views
9

Thiết kế nào bạn nghĩ chạy nhanh hơn trên PostgreSQL?Trong PostgreSQL, có nhanh hơn bao gồm các cột văn bản trong cùng một bảng, chứ không phải là một bảng riêng biệt?

  1. Tạo một cột 15 cột varchars và các loại tương tự, nhưng đặt tất cả các cột TEXT trong một bảng riêng biệt có liên kết fkey trở lại bảng này. Và hãy tưởng tượng bạn muốn tìm kiếm bản ghi có ID là "4" nhưng sau đó kéo tất cả các hàng trở lại, bao gồm cả nội dung từ các cột TEXT trong bảng đã tham gia. Và hãy tưởng tượng các bảng có 500.000 hàng.

  2. Tạo một bảng 15 cột varchars và các loại tương tự, và bao gồm các cột TEXT của bạn trong cùng một bảng. Một lần nữa, hãy tưởng tượng giống như trên - lấy bản ghi ID 4 và kéo toàn bộ bản ghi, và có 500.000 hàng trong bảng.

Ý tôi là, trong hầu hết các cơ sở dữ liệu, cách tôi hiểu, khi bạn đi xuống lớp vật lý về cách các cột TEXT hoạt động, chúng giữ một ID nhỏ thực sự trong cột của bảng trên mỗi hàng và ID đó đi đến một khối trang riêng biệt, độc quyền (hoặc danh pháp khác) trong cơ sở dữ liệu. Vì vậy, đối với tôi, dường như tùy chọn B sẽ chạy nhanh hơn vì không cần chi phí cho việc tham gia fkey và vì các cột TEXT không thực sự chiếm nhiều hơn một không gian nguyên trong cột đó trong bảng đã cho - và số nguyên đó là một khóa trong cơ sở dữ liệu vào một khối trang ở một nơi khác.

Trả lời

3

(B) là chính xác, vì lý do được đưa ra trong câu hỏi.

16

PostgreSQL không xử lý các cột TEXT giống như các DBMS khác.

Từ tài liệu của họ:

Mẹo: Không có sự khác biệt về hiệu năng giữa ba loại, ngoài việc tăng kích thước lưu trữ khi sử dụng các loại trống độn, và một vài chu kỳ để kiểm tra độ dài khi lưu trữ vào một cột bị giới hạn độ dài. Trong khi ký tự (n) có lợi thế về hiệu suất trong một số hệ thống cơ sở dữ liệu khác, nó không có những lợi thế như vậy trong PostgreSQL. Trong hầu hết các trường hợp, văn bản hoặc ký tự khác nhau nên được sử dụng thay thế.

Check out the manual

+0

+1 cho đào lên cụm từ chính xác rằng tôi sẽ làm gì khi tôi đọc câu hỏi! – some

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