Cả hai đều có các câu lệnh chuẩn bị. pg_ * là trình bao bọc cho libpq. Đúng?Các hàm PDO và pg_ *
Tôi thích PDO bằng PHP, nhưng tôi sẽ không thay đổi cơ sở dữ liệu trong tương lai. Tôi nên sử dụng thư viện nào? Bất kỳ điểm chuẩn nào? PHP phiên bản: 5.4
IMHO sử dụng các chức năng mà cách tiếp cận cụ thể trực tiếp DB (như pg_, oci_, mysql[i]_ vv) luôn luôn là một chút nhanh hơn là sau đó sử dụng một PDO hay bất kỳ lớp DBMS (Doctrine, dibi, vv) .
Nhưng sử dụng PDO hoặc bất kỳ lớp DBMS nào trong kiến trúc OOP nên tiếp cận tốt hơn (IMHO, lần nữa), khi bạn học cách sử dụng lớp này và do đó sẽ sử dụng nó trên bất kỳ công cụ DB nào phía sau. Tất nhiên nếu bạn thay đổi công cụ DB trong ứng dụng Bạn không phải bận tâm với việc viết lại toàn bộ ứng dụng.
Thậm chí nếu bạn không có ý định thay đổi công cụ DB, tôi khuyên bạn nên sử dụng PDO. Nhưng đó chỉ là ý kiến của tôi :-)
Tôi nghĩ rằng đây là một vấn đề của hương vị. PDO có thể nhanh hơn vì được biên dịch hoặc có thể không phải vì nó đóng vai trò như một trình bao bọc. Tôi chắc chắn rằng sự khác biệt về tốc độ sẽ đủ nhỏ để không ảnh hưởng đến quyết định của bạn.
Đây là suy đoán, nhưng PDO là mới và có vẻ là tiêu chuẩn cho các kết nối DB bây giờ, để hỗ trợ cho nó trong điều kiện của mã có thể sẽ phát triển, trong khi hỗ trợ cho mysql_* và có lẽ pg_* sẽ tiếp tục suy yếu dần.
Lợi thế chính của PDO là sự trừu tượng của nó sẽ cho phép bạn chuyển sang DB khác sau này, nhưng tôi cá là bạn sẽ không làm vậy, vì vậy có lẽ cũng không ảnh hưởng đến quyết định của bạn.
Cá nhân tôi thích làm việc với PDO. Việc truyền và điều khiển đối tượng dễ dàng hơn các biến "tài nguyên".
Nổ, bạn có chắc chắn không? Tôi mới với PHP và Postgre và bây giờ tôi cần phải quyết định công nghệ mà tôi sẽ sử dụng, tôi đã chạy một số xét nghiệm và pg_connect dường như nhanh hơn PDO. – HMarioD
PDO cung cấp một giao diện đẹp nhưng tính tổng quát hơn cũng có nghĩa là nhiều rắc rối hơn để đối phó với idiosyncrasies tinh tế của mỗi phụ trợ. Nếu bạn nhìn vào the bugtracker, nó có một số vấn đề mở và một số vấn đề nghiêm trọng.
Dưới đây là một bằng chứng giai thoại với postgresql: trình phân tích cú pháp của PDO gặp sự cố với standard_conforming_strings được đặt thành BẬT (hiện giờ là mặc định, như PG-9.1). trường hợp thử nghiệm với php-5.3.9:
$dbh->exec("SET standard_conforming_strings=on");
$p=$dbh->prepare("SELECT 1 WHERE 'ab\' = :foo AND 'cd' = :bar");
$p->execute(array(":foo" => "ab", ":bar" => "cd"));
Các thực() bất ngờ thất bại tại lớp PDO với Database error: SQLSTATE[HY093]: Invalid parameter number: :foo. Dường như nó không thể xác định: foo là một tham số.
Nếu truy vấn dừng sau 'ab\'=:foo, không có điều kiện khác, thì nó hoạt động tốt. Hoặc nếu điều kiện khác không bao gồm một chuỗi, nó cũng hoạt động tốt.
Sự cố có vẻ tương tự như issue #55335, đã bị loại bỏ là Không phải là lỗi, khá sai trong quan điểm của tôi. [Thực ra, tôi thậm chí đã tự mình hack PDO để sửa nó, nhưng theo cách không tương thích với các backend khác, vì vậy không có bản vá nào. Tôi đã bối rối bởi các phân tích từ vựng truy vấn được như vậy chung chung.]
Mặt khác, pg_ * gần hơn với libpq, loại sự cố này ít xảy ra hơn ở nơi đầu tiên và dễ giải quyết hơn nếu có.
Vì vậy, quan điểm của tôi sẽ không phải mọi thứ đều tốt đẹp với PDO. Bên trong, nó chắc chắn khó khăn hơn pg_ *, và phức tạp hơn có nghĩa là nhiều lỗi hơn. Các lỗi này có được giải quyết không? Dựa trên một số mục trình gỡ lỗi nhất định, không nhất thiết.
+1 Bài đăng tuyệt vời. Thực hiện quan điểm của bạn rất rõ ràng, chứng minh bằng chứng có liên quan. Luôn gần gũi hơn với RDBMS nhanh hơn và sạch hơn. –
@MorrisonHotel Xin lỗi tôi? – shadyyx
Nhận xét của tôi rất tệ, không phải Bạn :) – MorrisonHotel
PostgreSQL: ** SELECT TO_STRING (...) TỪ GIỚI HẠN CỦA TÔI 1 OFFSET 1 ** MySQL: ** CHỌN DATE_FORMAT (...) TỪ GIỚI HẠN CỦA TÔI 1.1 ** Như chúng ta thấy, ngay cả khi sử dụng PDO, tôi sẽ phải viết lại tất cả các yêu cầu tới cơ sở dữ liệu. Vì vậy, PDO không phải là thuốc chữa bách bệnh. Tôi sẽ phải sử dụng Doctrine, Propel, vv (bị loại trừ). – MorrisonHotel