PostgreSQL
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> PostgreSQL

Các phương pháp hay nhất về ghi nhật ký kiểm tra PostgreSQL

Trong mọi hệ thống CNTT nơi các nhiệm vụ kinh doanh quan trọng diễn ra, điều quan trọng là phải có một bộ chính sách và thực tiễn rõ ràng, đồng thời đảm bảo những chính sách và thực tiễn đó được tôn trọng và tuân thủ.

Giới thiệu về Kiểm toán

Đánh giá hệ thống Công nghệ thông tin là việc kiểm tra các chính sách, quy trình, thủ tục và thông lệ của một tổ chức liên quan đến cơ sở hạ tầng CNTT theo một số mục tiêu nhất định. Kiểm toán CNTT có thể có hai loại chung:

  • Kiểm tra theo một bộ tiêu chuẩn trên một tập hợp con dữ liệu hạn chế
  • Kiểm tra toàn bộ hệ thống

Kiểm toán CNTT có thể bao gồm một số bộ phận hệ thống quan trọng, chẳng hạn như các bộ phận liên quan đến dữ liệu tài chính để hỗ trợ một bộ quy định cụ thể (ví dụ:SOX) hoặc toàn bộ cơ sở hạ tầng bảo mật chống lại các quy định như quy định GDPR mới của EU nhằm giải quyết nhu cầu để bảo vệ quyền riêng tư và đặt ra các nguyên tắc quản lý dữ liệu cá nhân. Ví dụ SOX thuộc loại cũ được mô tả ở trên trong khi GDPR là loại sau.

Vòng đời kiểm tra

Lập kế hoạch

Phạm vi của một cuộc kiểm toán phụ thuộc vào mục tiêu kiểm toán. Phạm vi có thể bao gồm một ứng dụng đặc biệt được xác định bởi một hoạt động kinh doanh cụ thể, chẳng hạn như hoạt động tài chính hoặc toàn bộ cơ sở hạ tầng CNTT bao gồm bảo mật hệ thống, bảo mật dữ liệu, v.v. Phạm vi phải được xác định một cách chính xác trước đó như một bước sớm trong giai đoạn lập kế hoạch ban đầu. Tổ chức phải cung cấp cho đánh giá viên tất cả các thông tin cơ bản cần thiết để giúp lập kế hoạch đánh giá. Đây có thể là thông số kỹ thuật / chức năng, sơ đồ kiến ​​trúc hệ thống hoặc bất kỳ thông tin nào khác được yêu cầu.

Mục tiêu Kiểm soát

Dựa trên phạm vi, kiểm toán viên hình thành một tập hợp các mục tiêu kiểm soát cần được kiểm tra bởi cuộc kiểm toán. Các mục tiêu kiểm soát đó được thực hiện thông qua các thông lệ quản lý được cho là phải có nhằm đạt được kiểm soát trong phạm vi được mô tả. Các mục tiêu kiểm soát được liên kết với các kế hoạch thử nghiệm và các kế hoạch đó cùng tạo thành chương trình đánh giá. Dựa trên chương trình kiểm tra tổ chức được đánh giá phân bổ các nguồn lực để tạo điều kiện cho đánh giá viên.

Kết quả

Kiểm toán viên cố gắng thu thập bằng chứng rằng tất cả các mục tiêu kiểm soát đã được đáp ứng. Nếu đối với một số mục tiêu kiểm soát không có bằng chứng như vậy, trước tiên, kiểm toán viên thử xem có cách nào khác thay thế mà công ty xử lý mục tiêu kiểm soát cụ thể hay không và trong trường hợp cách thức đó tồn tại thì mục tiêu kiểm soát này được đánh dấu là bù đắp và đánh giá viên cho rằng mục tiêu đã được đáp ứng. Tuy nhiên, nếu không có bằng chứng nào cho thấy một mục tiêu được đáp ứng, thì điều này được đánh dấu là một phát hiện . Mỗi phát hiện bao gồm điều kiện, tiêu chí, nguyên nhân, kết quả và khuyến nghị. Người quản lý CNTT phải liên hệ chặt chẽ với đánh giá viên để được thông báo về tất cả các phát hiện tiềm ẩn và đảm bảo rằng tất cả thông tin được yêu cầu được chia sẻ giữa ban quản lý và đánh giá viên để đảm bảo rằng mục tiêu kiểm soát được đáp ứng (và do đó tránh tìm kiếm).

Báo cáo đánh giá

Vào cuối quá trình đánh giá, kiểm toán viên sẽ viết một báo cáo đánh giá như một bản tóm tắt bao gồm tất cả các phần quan trọng của cuộc đánh giá, bao gồm bất kỳ phát hiện tiềm năng nào, sau đó là tuyên bố về việc liệu mục tiêu có được giải quyết đầy đủ hay không và các khuyến nghị để loại bỏ ảnh hưởng của các phát hiện.

Ghi nhật ký kiểm tra là gì và tại sao bạn nên làm điều đó?

Đánh giá viên muốn có toàn quyền truy cập vào các thay đổi trên phần mềm, dữ liệu và hệ thống bảo mật. Anh ấy / cô ấy không chỉ muốn có thể theo dõi bất kỳ thay đổi nào đối với dữ liệu kinh doanh mà còn theo dõi các thay đổi đối với sơ đồ tổ chức, chính sách bảo mật, định nghĩa về vai trò / nhóm và những thay đổi đối với vai trò / thành viên nhóm. Cách phổ biến nhất để thực hiện kiểm tra là thông qua ghi nhật ký. Mặc dù trước đây có thể vượt qua cuộc kiểm tra CNTT mà không cần tệp nhật ký, nhưng ngày nay đây là cách được ưu tiên (nếu không phải là duy nhất).

Thông thường, hệ thống CNTT trung bình bao gồm ít nhất hai lớp:

  • Cơ sở dữ liệu
  • Ứng dụng (có thể nằm trên máy chủ ứng dụng)

Ứng dụng duy trì nhật ký của riêng nó bao gồm quyền truy cập và hành động của người dùng, cơ sở dữ liệu và có thể cả hệ thống máy chủ ứng dụng duy trì nhật ký của riêng họ. Thông tin sạch, dễ sử dụng trong các tệp nhật ký có giá trị kinh doanh thực từ góc độ kiểm toán viên được gọi là dấu vết kiểm toán . Các đường mòn kiểm tra khác với các tệp nhật ký thông thường (đôi khi được gọi là nhật ký gốc) ở chỗ:

  • Các tệp nhật ký là không thể thiếu
  • Các dấu vết kiểm tra nên được duy trì trong thời gian dài hơn
  • Các tệp nhật ký thêm chi phí vào tài nguyên của hệ thống
  • Mục đích của tệp nhật ký là giúp quản trị viên hệ thống
  • Mục đích của đường mòn đánh giá là giúp đánh giá viên

Chúng tôi tóm tắt những điều trên trong bảng sau:

Loại nhật ký Ứng dụng / Hệ thống Thân thiện với Đường kiểm tra
Nhật ký ứng dụng Ứng dụng
Nhật ký máy chủ ứng dụng Hệ thống Không
Nhật ký cơ sở dữ liệu Hệ thống Không

Nhật ký ứng dụng có thể dễ dàng được điều chỉnh để sử dụng làm đường dẫn kiểm tra. Nhật ký hệ thống không dễ dàng như vậy vì:

  • Chúng bị giới hạn về định dạng bởi phần mềm hệ thống
  • Họ hoạt động trên phạm vi toàn cầu trên toàn hệ thống
  • Họ không có kiến ​​thức trực tiếp về bối cảnh kinh doanh cụ thể
  • Chúng thường yêu cầu phần mềm bổ sung để phân tích / xử lý ngoại tuyến sau này nhằm tạo ra các đường dẫn kiểm tra thân thiện với kiểm toán có thể sử dụng được.

Tuy nhiên, mặt khác, Nhật ký ứng dụng đặt một lớp phần mềm bổ sung lên trên dữ liệu thực tế, do đó:

  • Làm cho hệ thống kiểm tra dễ bị lỗi ứng dụng / cấu hình sai
  • Tạo lỗ hổng tiềm ẩn trong quá trình ghi nhật ký nếu ai đó cố gắng truy cập dữ liệu trực tiếp trên cơ sở dữ liệu bằng cách bỏ qua hệ thống ghi nhật ký ứng dụng, chẳng hạn như người dùng đặc quyền hoặc DBA
  • Làm cho hệ thống kiểm toán trở nên phức tạp hơn và khó quản lý và duy trì hơn trong trường hợp chúng tôi có nhiều ứng dụng hoặc nhiều nhóm phần mềm.

Vì vậy, lý tưởng nhất là chúng tôi sẽ tìm kiếm điều tốt nhất trong số hai điều này:Có các đường dẫn kiểm tra có thể sử dụng với mức độ bao phủ lớn nhất trên toàn bộ hệ thống bao gồm cả lớp cơ sở dữ liệu và có thể định cấu hình ở một nơi, để bản thân nhật ký có thể được kiểm tra dễ dàng bằng các phương tiện khác ( hệ thống) nhật ký.

Ghi nhật ký kiểm tra với PostgreSQL

Các tùy chọn chúng tôi có trong PostgreSQL liên quan đến ghi nhật ký kiểm tra như sau:

  • Bằng cách sử dụng ghi nhật ký đầy đủ (log_statement =all)
  • Bằng cách viết một giải pháp kích hoạt tùy chỉnh
  • Bằng cách sử dụng các công cụ PostgreSQL tiêu chuẩn do cộng đồng cung cấp, chẳng hạn như
    • Audit-trigger 91plus (https://github.com/2ndQuadrant/audit-trigger)
    • tiện ích mở rộng pgaudit (https://github.com/pgaudit/pgaudit)

Cần tránh ghi nhật ký cạn kiệt ít nhất để sử dụng tiêu chuẩn trong khối lượng công việc OLTP hoặc OLAP vì:

  • Tạo các tệp lớn, tăng tải
  • Không có kiến ​​thức bên trong về các bảng đang được truy cập hoặc sửa đổi, chỉ in câu lệnh có thể là một khối DO với một câu lệnh được nối khó hiểu
  • Cần phần mềm / tài nguyên bổ sung để phân tích cú pháp và xử lý ngoại tuyến (để tạo ra các đường đánh giá) do đó chúng phải được đưa vào phạm vi đánh giá để được coi là đáng tin cậy

Trong phần còn lại của bài viết này, chúng tôi sẽ thử các công cụ do cộng đồng cung cấp. Giả sử rằng chúng ta có bảng đơn giản này muốn kiểm tra:

myshop=# \d orders
                                       Table "public.orders"
   Column   |           Type           | Collation | Nullable |              Default               
------------+--------------------------+-----------+----------+------------------------------------
 id         | integer                  |           | not null | nextval('orders_id_seq'::regclass)
 customerid | integer                  |           | not null |
 customer   | text                     |           | not null |
 xtime      | timestamp with time zone   |           | not null | now()
 productid  | integer                  |           | not null |
 product    | text                     |           | not null |
 quantity   | integer                  |           | not null |
 unit_price | double precision         |           | not null |
 cur        | character varying(20)    |           | not null | 'EUR'::character varying
Indexes:
    "orders_pkey" PRIMARY KEY, btree (id)

Audit-trigger 91plus

Bạn có thể tìm thấy tài liệu về cách sử dụng trình kích hoạt tại đây:https://wiki.postgresql.org/wiki/Audit_trigger_91plus. Đầu tiên, chúng tôi tải xuống và cài đặt DDL (hàm, lược đồ) được cung cấp:

$ wget https://raw.githubusercontent.com/2ndQuadrant/audit-trigger/master/audit.sql
$ psql myshop
psql (10.3 (Debian 10.3-1.pgdg80+1))
Type "help" for help.
myshop=# \i audit.sql

Sau đó, chúng tôi xác định các trình kích hoạt cho các đơn đặt hàng trong bảng của chúng tôi bằng cách sử dụng cơ bản:

myshop=# SELECT audit.audit_table('orders');

Điều này sẽ tạo hai trình kích hoạt theo thứ tự bảng:trình kích hoạt hàng insert_update_delere và trình kích hoạt câu lệnh cắt ngắn. Bây giờ chúng ta hãy xem trình kích hoạt làm gì:

myshop=# insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);      
INSERT 0 1
myshop=# update orders set quantity=3 where id=2;
UPDATE 1
myshop=# delete from orders  where id=2;
DELETE 1
myshop=# select table_name, action, session_user_name, action_tstamp_clk, row_data, changed_fields from audit.logged_actions;
-[ RECORD 1 ]-----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
table_name        | orders
action            | I
session_user_name | postgres
action_tstamp_clk | 2018-05-20 00:15:10.887268+03
row_data          | "id"=>"2", "cur"=>"EUR", "xtime"=>"2018-05-20 00:15:10.883801+03", "product"=>"some fn skin 2", "customer"=>"magicbattler", "quantity"=>"2", "productid"=>"2", "customerid"=>"1", "unit_price"=>"5"
changed_fields    |
-[ RECORD 2 ]-----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
table_name        | orders
action            | U
session_user_name | postgres
action_tstamp_clk | 2018-05-20 00:16:12.829065+03
row_data          | "id"=>"2", "cur"=>"EUR", "xtime"=>"2018-05-20 00:15:10.883801+03", "product"=>"some fn skin 2", "customer"=>"magicbattler", "quantity"=>"2", "productid"=>"2", "customerid"=>"1", "unit_price"=>"5"
changed_fields    | "quantity"=>"3"
-[ RECORD 3 ]-----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
table_name        | orders
action            | D
session_user_name | postgres
action_tstamp_clk | 2018-05-20 00:16:24.944117+03
row_data          | "id"=>"2", "cur"=>"EUR", "xtime"=>"2018-05-20 00:15:10.883801+03", "product"=>"some fn skin 2", "customer"=>"magicbattler", "quantity"=>"3", "productid"=>"2", "customerid"=>"1", "unit_price"=>"5"
changed_fields    |

Lưu ý giá trị change_fields trên Bản cập nhật (GHI 2). Có nhiều cách sử dụng nâng cao hơn của trình kích hoạt kiểm tra, như loại trừ cột hoặc sử dụng mệnh đề WHEN như được hiển thị trong tài liệu. Trình kích hoạt kiểm tra dường như thực hiện công việc tạo ra các đường dẫn kiểm tra hữu ích bên trong bảng Audit.logged_actions. Tuy nhiên có một số lưu ý:

  • Không có CHỌN (trình kích hoạt không kích hoạt trên CHỌN) hoặc DDL được theo dõi
  • Các thay đổi của chủ sở hữu bảng và người dùng cấp cao có thể dễ dàng bị giả mạo
  • Các phương pháp hay nhất phải được tuân thủ liên quan đến (các) người dùng ứng dụng và chủ sở hữu bảng và lược đồ ứng dụng
Tải xuống Báo cáo chính thức hôm nay Quản lý &Tự động hóa PostgreSQL với ClusterControlTìm hiểu về những điều bạn cần biết để triển khai, giám sát, quản lý và mở rộng PostgreSQLTải xuống Báo cáo chính thức

Pgaudit

Pgaudit là phần bổ sung mới nhất cho PostgreSQL liên quan đến việc kiểm toán. Pgaudit phải được cài đặt dưới dạng tiện ích mở rộng, như được hiển thị trong trang github của dự án:https://github.com/pgaudit/pgaudit. Pgaudit ghi nhật ký PostgreSQL chuẩn. Pgaudit hoạt động bằng cách tự đăng ký khi tải mô-đun và cung cấp các móc cho thi hành chương trình khởi động, thực thiCheckPerms, processUtility và object_access. Do đó pgaudit (trái ngược với các giải pháp dựa trên trình kích hoạt như trình kích hoạt kiểm toán đã thảo luận trong các đoạn trước) hỗ trợ ĐỌC (CHỌN, SAO CHÉP). Nói chung với pgaudit, chúng ta có thể có hai chế độ hoạt động hoặc sử dụng chúng kết hợp:

  • Ghi nhật ký kiểm tra SESSION
  • Ghi nhật ký kiểm tra OBJECT

Ghi nhật ký kiểm tra phiên hỗ trợ hầu hết các lệnh DML, DDL, đặc quyền và các lệnh khác thông qua các lớp:

  • ĐỌC (chọn, sao chép từ)
  • VIẾT (chèn, cập nhật, xóa, cắt bớt, sao chép vào)
  • FUNCTION (lệnh gọi hàm và khối DO)
  • VAI TRÒ (cấp, thu hồi, tạo / thay đổi / loại bỏ vai trò)
  • DDL (tất cả DDL ngoại trừ những DDL trong ROLE)
  • MISC (loại bỏ, tìm nạp, điểm kiểm tra, chân không)

Metaclass “tất cả” bao gồm tất cả các lớp. - loại trừ một lớp. Ví dụ:hãy để chúng tôi định cấu hình ghi nhật ký kiểm tra Phiên cho tất cả ngoại trừ MISC, với các tham số GUC sau trong postgresql.conf:

pgaudit.log_catalog = off
pgaudit.log = 'all, -misc'
pgaudit.log_relation = 'on'
pgaudit.log_parameter = 'on'

Bằng cách đưa ra các lệnh sau (giống như trong ví dụ về trình kích hoạt)

myshop=# insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);
INSERT 0 1
myshop=# update orders set quantity=3 where id=2;
UPDATE 1
myshop=# delete from orders  where id=2;
DELETE 1
myshop=#

Chúng tôi nhận được các mục sau trong nhật ký PostgreSQL:

% tail -f data/log/postgresql-22.log | grep AUDIT:
[local] [55035] 5b03e693.d6fb 2018-05-22 12:46:37.352 EEST psql [email protected] line:7 LOG:  AUDIT: SESSION,5,1,WRITE,INSERT,TABLE,public.orders,"insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);",<none>
[local] [55035] 5b03e693.d6fb 2018-05-22 12:46:50.120 EEST psql [email protected] line:8 LOG:  AUDIT: SESSION,6,1,WRITE,UPDATE,TABLE,public.orders,update orders set quantity=3 where id=2;,<none>
[local] [55035] 5b03e693.d6fb 2018-05-22 12:46:59.888 EEST psql [email protected] line:9 LOG:  AUDIT: SESSION,7,1,WRITE,DELETE,TABLE,public.orders,delete from orders  where id=2;,<none>

Lưu ý rằng văn bản sau AUDIT:tạo nên một dấu vết kiểm tra hoàn hảo, gần như đã sẵn sàng để gửi cho kiểm toán viên ở định dạng csv sẵn sàng cho bảng tính. Sử dụng ghi nhật ký kiểm tra phiên sẽ cung cấp cho chúng tôi các mục nhập nhật ký kiểm tra cho tất cả các hoạt động thuộc các lớp được xác định bởi tham số pgaudit.log trên tất cả những cái bàn. Tuy nhiên, có những trường hợp chúng tôi chỉ muốn một tập hợp con nhỏ của dữ liệu, tức là chỉ một vài bảng được kiểm tra. Trong những trường hợp như vậy, chúng tôi có thể thích ghi nhật ký kiểm tra đối tượng, cung cấp cho chúng tôi các tiêu chí chi tiết cho các bảng / cột đã chọn thông qua hệ thống đặc quyền của PostgreSQL. Để bắt đầu sử dụng ghi nhật ký kiểm tra Đối tượng, trước tiên chúng ta phải định cấu hình tham số pgaudit.role để xác định vai trò chính mà pgaudit sẽ sử dụng. Không nên cấp cho người dùng này bất kỳ quyền đăng nhập nào.

CREATE ROLE auditor;
ALTER ROLE auditor WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN NOREPLICATION NOBYPASSRLS CONNECTION LIMIT 0;

Chúng tôi chỉ định giá trị này cho pgaudit.role trong postgresql.conf:

pgaudit.log = none # no need for extensive SESSION logging
pgaudit.role = auditor

Ghi nhật ký Pgaudit OBJECT sẽ hoạt động bằng cách tìm xem người dùng có kiểm toán viên được cấp (trực tiếp hoặc kế thừa) quyền thực hiện hành động được chỉ định được thực hiện trên các quan hệ / cột được sử dụng trong một câu lệnh. Vì vậy, nếu chúng ta cần bỏ qua tất cả các bảng, nhưng phải ghi nhật ký chi tiết vào các đơn đặt hàng trong bảng, thì đây là cách để làm điều đó:

grant ALL on orders to auditor ;

Bằng cách cấp trên, chúng tôi cho phép ghi đầy đủ CHỌN, CHÈN, CẬP NHẬT và XÓA trên các đơn đặt hàng trên bàn. Chúng ta hãy cung cấp một lần nữa CHÈN, CẬP NHẬT, XÓA của các ví dụ trước và xem nhật ký postgresql:

% tail -f data/log/postgresql-22.log | grep AUDIT:
[local] [60683] 5b040125.ed0b 2018-05-22 14:41:41.989 EEST psql [email protected] line:7 LOG:  AUDIT: OBJECT,2,1,WRITE,INSERT,TABLE,public.orders,"insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);",<none>
[local] [60683] 5b040125.ed0b 2018-05-22 14:41:52.269 EEST psql [email protected] line:8 LOG:  AUDIT: OBJECT,3,1,WRITE,UPDATE,TABLE,public.orders,update orders set quantity=3 where id=2;,<none>
[local] [60683] 5b040125.ed0b 2018-05-22 14:42:03.148 EEST psql [email protected] line:9 LOG:  AUDIT: OBJECT,4,1,WRITE,DELETE,TABLE,public.orders,delete from orders  where id=2;,<none>

Chúng tôi nhận thấy rằng kết quả đầu ra giống với ghi nhật ký SESSION đã thảo luận ở trên với sự khác biệt là thay vì SESSION làm loại kiểm toán (chuỗi bên cạnh AUDIT:) thì bây giờ chúng tôi nhận được OBJECT.

Một lưu ý với ghi nhật ký OBJECT là các TRUNCATE không được ghi nhật ký. Chúng tôi phải sử dụng ghi nhật ký SESSION cho việc này. Nhưng trong trường hợp này, chúng tôi nhận được tất cả hoạt động WRITE cho tất cả các bảng. Có những cuộc thảo luận giữa các tin tặc liên quan để biến mỗi lệnh trở thành một lớp riêng biệt.

Một điều khác cần lưu ý là trong trường hợp kế thừa nếu chúng ta CẤP quyền truy cập vào trình đánh giá trên một số bảng con, chứ không phải là bảng mẹ, các hành động trên bảng mẹ chuyển thành các hành động trên các hàng của bảng con sẽ không được ghi lại.

Ngoài những điều trên, nhân viên CNTT chịu trách nhiệm về tính toàn vẹn của nhật ký phải ghi lại một quy trình nghiêm ngặt và được xác định rõ ràng bao gồm việc trích xuất đường mòn kiểm tra từ các tệp nhật ký PostgreSQL. Các nhật ký đó có thể được truyền trực tuyến đến một máy chủ nhật ký hệ thống bảo mật bên ngoài để giảm thiểu khả năng bị can thiệp hoặc giả mạo.

Tóm tắt

Chúng tôi hy vọng blog này đã giúp bạn hiểu rõ hơn về các phương pháp hay nhất để đăng nhập kiểm tra trong PostgreSQL và tại sao việc tạo lộ trình kiểm tra lại quan trọng như vậy trong việc chuẩn bị cho kiểm tra CNTT. Lộ trình đánh giá sẽ cung cấp một tập hợp thông tin sạch, có thể sử dụng được sẽ giúp quá trình đánh giá của bạn diễn ra suôn sẻ.

ClusterControl có thể giúp tự động hóa và quản lý hầu hết các tác vụ liên quan đến cơ sở dữ liệu trong khi vẫn đảm bảo tính bảo mật, tính khả dụng và hiệu suất của cơ sở dữ liệu - bất kể hệ thống bạn chọn là gì. Tải xuống bản dùng thử miễn phí của ClusterControl ngay hôm nay để xem doanh nghiệp của bạn có thể hưởng lợi như thế nào từ công cụ và các hoạt động mà nó thực hiện. Nếu bạn chưa theo dõi, hãy đảm bảo theo dõi chúng tôi trên Twitter và LinkedIn, đồng thời đăng ký nguồn cấp dữ liệu của chúng tôi và chúng tôi sẽ gặp bạn trong blog tiếp theo.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Làm cách nào để cài đặt Postgis thành bản cài đặt Keg của [email bảo vệ] bằng Homebrew?

  2. Có nhóm theo điều khoản - elein’s GeneralBits

  3. Làm cách nào để chèn JSONB vào Postgresql bằng Python?

  4. Tạo cơ sở dữ liệu PostgreSQL

  5. cập nhật truy vấn với phép nối trên hai bảng