Làm cách nào để chèn dữ liệu chung vào bảng tạm thời từ các lược đồ khác nhau?

Trước tiên, bạn có thể tạo VIEW để cung cấp chức năng này:

CREATE VIEW orders AS
SELECT '1'::int            AS source -- or any other tag to identify source
      ,"OrderNumber"::text AS order_nr
      ,"InvoiceNumber"     AS tansaction_id -- no cast .. is int already
      ,"OrderDate" AT TIME ZONE 'UTC' AS purchase_date -- !! see explanation
FROM   tbl_newegg

UNION  ALL  -- not UNION!
SELECT 2
       "amazonOrderId"
      ,"merchant-order-id"
      ,"purchase-date"
FROM   tbl_amazon;

Bạn có thể truy vấn chế độ xem này giống như bất kỳ bảng nào khác:

SELECT * FROM orders WHERE order_nr = 123 AND source = 2;

Nguồn source là cần thiết nếu order_nr không phải là duy nhất. Làm cách nào khác mà bạn đảm bảo số đơn đặt hàng duy nhất trên các nguồn khác nhau?
Dấu thời gian timestamp without time zone là một sự mơ hồ trong bối cảnh toàn cầu. Nó chỉ tốt khi kết nối với múi giờ của nó. Nếu bạn kết hợp timestamp và timestamptz , bạn cần đặt timestamp tại một múi giờ nhất định với AT TIME ZONE xây dựng để làm cho công việc này. Để biết thêm giải thích, hãy đọc câu trả lời liên quan này .

Tôi sử dụng UTC làm múi giờ, bạn có thể muốn cung cấp một múi giờ khác. Truyền đơn giản "OrderDate"::timestamptz sẽ giả sử múi giờ hiện tại của bạn. AT TIME ZONE được áp dụng cho timestamp kết quả là timestamptz . Đó là lý do tại sao tôi không thêm một dàn diễn viên khác.
Trong khi bạn có thể , Tôi khuyên bạn không nên sử dụng số nhận dạng camel-case trong PostgreSQL đã từng . Tránh nhiều loại nhầm lẫn có thể xảy ra. Lưu ý các số nhận dạng viết thường (không có dấu ngoặc kép hiện không cần thiết) mà tôi đã cung cấp.
Không sử dụng varchar(25) làm loại cho order_nr . Chỉ cần sử dụng text không có công cụ sửa đổi độ dài tùy ý nếu nó phải là một chuỗi. Nếu tất cả các số đơn đặt hàng chỉ bao gồm các chữ số, integer hoặc bigint sẽ nhanh hơn.

Hiệu suất

Một cách để thực hiện điều này nhanh chóng là hiện thực hóa chế độ xem. Tức là ghi kết quả vào một bảng (tạm thời):

CREATE TEMP TABLE tmp_orders AS
SELECT * FROM orders;

ANALYZE tmp_orders; -- temp tables are not auto-analyzed!

ALTER TABLE tmp_orders
ADD constraint orders_pk PRIMARY KEY (order_nr, source);

Bạn cần một chỉ số. Trong ví dụ của tôi, ràng buộc khóa chính cung cấp chỉ mục tự động.

Nếu bảng của bạn lớn, hãy đảm bảo bạn có đủ bộ đệm tạm thời để xử lý vấn đề này trong RAM trước bạn tạo bảng tạm thời. Nếu không, nó sẽ thực sự làm bạn chậm lại.

SET temp_buffers = 1000MB;

Phải là lệnh gọi đầu tiên đến các đối tượng tạm thời trong phiên của bạn. Đừng đặt nó cao trên toàn cầu, chỉ cho phiên của bạn. Bảng tạm thời vẫn tự động bị xóa vào cuối phiên của bạn.

Để ước tính lượng RAM bạn cần, hãy tạo bảng một lần và đo:

SELECT pg_size_pretty(pg_total_relation_size('tmp_orders'));

Tìm hiểu thêm về kích thước đối tượng trong câu hỏi liên quan trên dba.SE này .

Tất cả chi phí chỉ thanh toán nếu bạn phải xử lý một số truy vấn trong một phiên. Đối với các trường hợp sử dụng khác, có các giải pháp khác. Nếu bạn biết bảng nguồn tại thời điểm truy vấn, sẽ nhanh hơn nhiều để chuyển truy vấn của bạn đến bảng nguồn. Nếu bạn không, tôi sẽ đặt câu hỏi về tính duy nhất của order_nr của bạn một lần nữa. Trên thực tế, nếu nó được đảm bảo là duy nhất, bạn có thể bỏ cột source Tôi đã giới thiệu.

Đối với chỉ một hoặc một vài truy vấn, việc sử dụng chế độ xem thay vì chế độ xem cụ thể hóa có thể nhanh hơn.

Tôi cũng sẽ xem xét một hàm plpgsql truy vấn bảng này đến bảng khác cho đến khi bản ghi được tìm thấy. Có thể rẻ hơn cho một vài truy vấn, xem xét chi phí. Tất nhiên, chỉ mục cho mọi bảng cần thiết.

Ngoài ra, nếu bạn dính vào text hoặc varchar cho order_nr của bạn , hãy xem xét COLLATE "C" cho nó.