PostgreSQL的NoSQL特性

注意：键值对的键必须使用双引号

查询JSONB中字段

根据某一键值查找

示例：

functions-json

右 *** 作符为int： 获取JSON数组元素（索引从0开始）

右 *** 作符为text： 通过键获取json值

右 *** 作符为int： 获取JSON数组元素为text

右 *** 作符为text： 通过键获取json值为text

右 *** 作符为: text[] , 在指定的路径获取JSON对象。

即在获取 ab 的值

右 *** 作符为: text[] , 在指定的路径获取JSON对象为text

即获取 a[2] 的值并转为text

右 *** 作数的类型： jsonb , 左侧的JSONB的是否包含右侧的

右 *** 作数的类型： jsonb , 右侧的JSONB的是否包含左侧的

右 *** 作符: text , 该字符串是否存在于json的顶级key中

右 *** 作符： text[] ，所有这些元素是否存都在于json的顶级key中

右 *** 作符: jsonb , 拼接两个 jsonb 生成一个新的 jsonb

右 *** 作符： text ，从左 *** 作数中删除K/V或者字符串元素。

右 *** 作符： int ， 删除指定索引的元素（负数表示从结尾开始）

右 *** 作符： text[] ， 删除字段或指定路径的元素

json(jsonb)中的CRUD

添加jsonb的字段

删除jsonb的某字段

请尝试OLEDB或ODBC的方式连接PostgreSQL数据库。

当然，首先需要从PostgreSQL官网获取OLEDB或ODBC的驱动程序，然后才可以使用。

目前用ASP开发的越来越少了，都已经使用ASPNET开发了，就可以直接使用PostgreSQL提供的ADO NET Provider来连接数据库并进行 *** 作。

一、使用EXPLAIN：

PostgreSQL为每个查询都生成一个查询规划，因为选择正确的查询路径对性能的影响是极为关键的。PostgreSQL本身已经包含了一个规划器用于寻找最优规划，我们可以通过使用EXPLAIN命令来查看规划器为每个查询生成的查询规划。

PostgreSQL中生成的查询规划是由1到n个规划节点构成的规划树，其中最底层的节点为表扫描节点，用于从数据表中返回检索出的数据行。然而，不同

的扫描节点类型代表着不同的表访问模式，如：顺序扫描、索引扫描，以及位图索引扫描等。如果查询仍然需要连接、聚集、排序，或者是对原始行的其它 *** 作，那

么就会在扫描节点"之上"有其它额外的节点。并且这些 *** 作通常都有多种方法，因此在这些位置也有可能出现不同的节点类型。EXPLAIN将为规划树中的每

个节点都输出一行信息，显示基本的节点类型和规划器为执行这个规划节点计算出的预计开销值。第一行(最上层的节点)是对该规划的总执行开销的预计，这个数

值就是规划器试图最小化的数值。

这里有一个简单的例子，如下：

复制代码 代码如下:

EXPLAIN SELECT FROM tenk1;

QUERY PLAN

-------------------------------------------------------------

Seq Scan on tenk1 (cost=00045800 rows=10000 width=244)

EXPLAIN引用的数据是：

1) 预计的启动开销(在输出扫描开始之前消耗的时间，比如在一个排序节点里做排续的时间)。

2) 预计的总开销。

3) 预计的该规划节点输出的行数。

4) 预计的该规划节点的行平均宽度(单位：字节)。

这里开销(cost)的计算单位是磁盘页面的存取数量，如10将表示一次顺序的磁盘页面读取。其中上层节点的开销将包括其所有子节点的开销。这里的输出

行数(rows)并不是规划节点处理/扫描的行数，通常会更少一些。一般而言，顶层的行预计数量会更接近于查询实际返回的行数。

现在我们执行下面基于系统表的查询：

复制代码 代码如下:

SELECT relpages, reltuples FROM pg_class WHERE relname = 'tenk1';

从查询结果中可以看出tenk1表占有358个磁盘页面和10000条记录，然而为了计算cost的值，我们仍然需要知道另外一个系统参数值。

复制代码 代码如下:

postgres=# show cpu_tuple_cost;

cpu_tuple_cost

----------------

001

(1 row)

cost = 358(磁盘页面数) + 10000(行数) 001(cpu_tuple_cost系统参数值)

下面我们再来看一个带有WHERE条件的查询规划。

复制代码 代码如下:

EXPLAIN SELECT FROM tenk1 WHERE unique1 < 7000;

QUERY PLAN

------------------------------------------------------------

Seq Scan on tenk1 (cost=00048300 rows=7033 width=244)

Filter: (unique1 < 7000)

EXPLAIN的输出显示，WHERE子句被当作一个"filter"应用，这表示该规划节点将扫描表中的每一行数据，之后再判定它们是否符合过滤的条

件，最后仅输出通过过滤条件的行数。这里由于WHERE子句的存在，预计的输出行数减少了。即便如此，扫描仍将访问所有10000行数据，因此开销并没有

真正降低，实际上它还增加了一些因数据过滤而产生的额外CPU开销。

上面的数据只是一个预计数字，即使是在每次执行ANALYZE命令之后也会随之改变，因为ANALYZE生成的统计数据是通过从该表中随机抽取的样本计算的。

如果我们将上面查询的条件设置的更为严格一些的话，将会得到不同的查询规划，如：

复制代码 代码如下:

EXPLAIN SELECT FROM tenk1 WHERE unique1 < 100;

QUERY PLAN

------------------------------------------------------------------------------

Bitmap Heap Scan on tenk1 (cost=23723235 rows=106 width=244)

Recheck Cond: (unique1 < 100)

-> Bitmap Index Scan on tenk1_unique1 (cost=000237 rows=106 width=0)

Index Cond: (unique1 < 100)

这里，规划器决定使用两步规划，最内层的规划节点访问一个索引，找出匹配索引条件的行的位置，然后上层规划节点再从表里读取这些行。单独地读取数据行比顺

序地读取它们的开销要高很多，但是因为并非访问该表的所有磁盘页面，因此该方法的开销仍然比一次顺序扫描的开销要少。这里使用两层规划的原因是因为上层规

划节点把通过索引检索出来的行的物理位置先进行排序，这样可以最小化单独读取磁盘页面的开销。节点名称里面提到的"位图(bitmap)"是进行排序的机

制。

现在我们还可以将WHERE的条件设置的更加严格，如：

复制代码 代码如下:

EXPLAIN SELECT FROM tenk1 WHERE unique1 < 3;

QUERY PLAN

------------------------------------------------------------------------------

Index Scan using tenk1_unique1 on tenk1 (cost=0001000 rows=2 width=244)

Index Cond: (unique1 < 3)

在该SQL中，表的数据行是以索引的顺序来读取的，这样就会令读取它们的开销变得更大，然而事实上这里将要获取的行数却少得可怜，因此没有必要在基于行的物理位置进行排序了。

现在我们需要向WHERE子句增加另外一个条件，如：

复制代码 代码如下:

EXPLAIN SELECT FROM tenk1 WHERE unique1 < 3 AND stringu1 = 'xxx';

QUERY PLAN

------------------------------------------------------------------------------

Index Scan using tenk1_unique1 on tenk1 (cost=0001001 rows=1 width=244)

Index Cond: (unique1 < 3)

Filter: (stringu1 = 'xxx'::name)

新增的过滤条件stringu1 = 'xxx'只是减少了预计输出的行数，但是并没有减少实际开销，因为我们仍然需要访问相同数量的数据行。而该条件并没有作为一个索引条件，而是被当成对索引结果的过滤条件来看待。

如果WHERE条件里有多个字段存在索引，那么规划器可能会使用索引的AND或OR的组合，如：

复制代码 代码如下:

EXPLAIN SELECT FROM tenk1 WHERE unique1 < 100 AND unique2 > 9000;

QUERY PLAN

-------------------------------------------------------------------------------------

Bitmap Heap Scan on tenk1 (cost=11274911 rows=11 width=244)

Recheck Cond: ((unique1 < 100) AND (unique2 > 9000))

-> BitmapAnd (cost=11271127 rows=11 width=0)

-> Bitmap Index Scan on tenk1_unique1 (cost=000237 rows=106 width=0)

Index Cond: (unique1 < 100)

-> Bitmap Index Scan on tenk1_unique2 (cost=000865 rows=1042 width=0)

Index Cond: (unique2 > 9000)

这样的结果将会导致访问两个索引，与只使用一个索引，而把另外一个条件只当作过滤器相比，这个方法未必是更优。

现在让我们来看一下基于索引字段进行表连接的查询规划，如：

复制代码 代码如下:

EXPLAIN SELECT FROM tenk1 t1, tenk2 t2 WHERE t1unique1 < 100 AND t1unique2 = t2unique2;

QUERY PLAN

--------------------------------------------------------------------------------------

Nested Loop (cost=23755311 rows=106 width=488)

-> Bitmap Heap Scan on tenk1 t1 (cost=23723235 rows=106 width=244)

Recheck Cond: (unique1 < 100)

-> Bitmap Index Scan on tenk1_unique1 (cost=000237 rows=106 width=0)

Index Cond: (unique1 < 100)

-> Index Scan using tenk2_unique2 on tenk2 t2 (cost=000301 rows=1 width=244)

Index Cond: ("outer"unique2 = t2unique2)

从查询规划中可以看出(Nested

Loop)该查询语句使用了嵌套循环。外层的扫描是一个位图索引，因此其开销与行计数和之前查询的开销是相同的，这是因为条件unique1 <

100发挥了作用。 这个时候t1unique2 =

t2unique2条件子句还没有产生什么作用，因此它不会影响外层扫描的行计数。然而对于内层扫描而言，当前外层扫描的数据行将被插入到内层索引扫描

中，并生成类似的条件t2unique2 = constant。所以，内层扫描将得到和EXPLAIN SELECT FROM tenk2

WHERE unique2 = 42一样的计划和开销。最后，以外层扫描的开销为基础设置循环节点的开销，再加上每个外层行的一个迭代(这里是 106

301)，以及连接处理需要的一点点CPU时间。

如果不想使用嵌套循环的方式来规划上面的查询，那么我们可以通过执行以下系统设置，以关闭嵌套循环，如：

复制代码 代码如下:

SET enable_nestloop = off;

EXPLAIN SELECT FROM tenk1 t1, tenk2 t2 WHERE t1unique1 < 100 AND t1unique2 = t2unique2;

QUERY PLAN

------------------------------------------------------------------------------------------

Hash Join (cost=2326174167 rows=106 width=488)

Hash Cond: ("outer"unique2 = "inner"unique2)

-> Seq Scan on tenk2 t2 (cost=00045800 rows=10000 width=244)

-> Hash (cost=2323523235 rows=106 width=244)

-> Bitmap Heap Scan on tenk1 t1 (cost=23723235 rows=106 width=244)

Recheck Cond: (unique1 < 100)

-> Bitmap Index Scan on tenk1_unique1 (cost=000237 rows=106 width=0)

Index Cond: (unique1 < 100)

这个规划仍然试图用同样的索引扫描从tenk1里面取出符合要求的100行，并把它们存储在内存中的散列(哈希)表里，然后对tenk2做一次全表顺序扫

描，并为每一条tenk2中的记录查询散列(哈希)表，寻找可能匹配t1unique2 =

t2unique2的行。读取tenk1和建立散列表是此散列联接的全部启动开销，因为我们在开始读取tenk2之前不可能获得任何输出行。

此外，我们还可以用EXPLAIN ANALYZE命令检查规划器预估值的准确性。这个命令将先执行该查询，然后显示每个规划节点内实际运行时间，以及单纯EXPLAIN命令显示的预计开销，如：

复制代码 代码如下:

EXPLAIN ANALYZE SELECT FROM tenk1 t1, tenk2 t2 WHERE t1unique1 < 100 AND t1unique2 = t2unique2;

QUERY PLAN

----------------------------------------------------------------------------------------------------------------------------------

Nested Loop (cost=23755311 rows=106 width=488) (actual time=139212700 rows=100 loops=1)

-> Bitmap Heap Scan on tenk1 t1 (cost=23723235 rows=106 width=244) (actual time=08782367 rows=100 loops=1)

Recheck Cond: (unique1 < 100)

-> Bitmap Index Scan on tenk1_unique1 (cost=000237

rows=106 width=0) (actual time=05460546 rows=100 loops=1)

Index Cond: (unique1 < 100)

-> Index Scan using tenk2_unique2 on tenk2 t2

(cost=000301 rows=1 width=244) (actual time=00670078 rows=1

loops=100)

Index Cond: ("outer"unique2 = t2unique2)

Total runtime: 14452 ms

注意"actual time"数值是以真实时间的毫秒来计算的，而"cost"预估值是以磁盘页面读取数量来计算的，所以它们很可能是不一致的。然而我们需要关注的只是两组数据的比值是否一致。

在一些查询规划里，一个子规划节点很可能会运行多次，如之前的嵌套循环规划，内层的索引扫描会为每个外层行执行一次。在这种情况下，"loops"将报告

该节点执行的总次数，而显示的实际时间和行数目则是每次执行的平均值。这么做的原因是令这些真实数值与开销预计显示的数值更具可比性。如果想获得该节点所

花费的时间总数，计算方式是用该值乘以"loops"值。

EXPLAIN ANALYZE显示的"Total runtime"包括执行器启动和关闭的时间，以及结果行处理的时间，但是它并不包括分析、重写或者规划的时间。

如果EXPLAIN命令仅能用于测试环境，而不能用于真实环境，那它就什么用都没有。比如，在一个数据较少的表上执行EXPLAIN，它不能适用于数量很

多的大表，因为规划器的开销计算不是线性的，因此它很可能对大些或者小些的表选择不同的规划。一个极端的例子是一个只占据一个磁盘页面的表，在这样的表

上，不管它有没有索引可以使用，你几乎都总是得到顺序扫描规划。规划器知道不管在任何情况下它都要进行一个磁盘页面的读取，所以再增加几个磁盘页面读取用

以查找索引是毫无意义的。

二、批量数据插入：

有以下几种方法用于优化数据的批量插入。

1 关闭自动提交：

在批量插入数据时，如果每条数据都被自动提交，当中途出现系统故障时，不仅不能保障本次批量插入的数据一致性，而且由于有多次提交 *** 作的发生，整个插入效

率也会受到很大的打击。解决方法是，关闭系统的自动提交，并且在插入开始之前，显示的执行begin

transaction命令，在全部插入 *** 作完成之后再执行commit命令提交所有的插入 *** 作。

2 使用COPY：

使用COPY在一条命令里装载所有记录，而不是一系列的INSERT命令。COPY命令是为装载数量巨大的数据行优化过的，它不像INSERT命令那样灵

活，但是在装载大量数据时，系统开销也要少很多。因为COPY是单条命令，因此在填充表的时就没有必要关闭自动提交了。

3 删除索引：

如果你正在装载一个新创建的表，最快的方法是创建表，用COPY批量装载，然后创建表需要的任何索引。因为在已存在数据的表上创建索引比维护逐行增加要快。当然在缺少索引期间，其它有关该表的查询 *** 作的性能将会受到一定的影响，唯一性约束也有可能遭到破坏。

4 删除外键约束：

和索引一样，"批量地"检查外键约束比一行行检查更加高效。因此，我们可以先删除外键约束，装载数据，然后在重建约束。

5 增大maintenance_work_mem：

在装载大量数据时，临时增大maintenance_work_mem系统变量的值可以改进性能。这个系统参数可以提高CREATE

INDEX命令和ALTER TABLE ADD FOREIGN KEY命令的执行效率，但是它不会对COPY *** 作本身产生多大的影响。

6 增大checkpoint_segments：

临时增大checkpoint_segments系统变量的值也可以提高大量数据装载的效率。这是因为在向PostgreSQL装载大量数据时，将会导致

检查点 *** 作(由系统变量checkpoint_timeout声明)比平时更加频繁的发生。在每次检查点发生时，所有的脏数据都必须flush到磁盘上。

通过提高checkpoint_segments变量的值，可以有效的减少检查点的数目。

7 事后运行ANALYZE：

在增加或者更新了大量数据之后，应该立即运行ANALYZE命令，这样可以保证规划器得到基于该表的最新数据统计。换句话说，如果没有统计数据或者统计数据太过陈旧，那么规划器很可能会选择一个较差的查询规划，从而导致查询效率过于低下。

了存储、查询和修改空间关系的能力。本文中 ‘PostgreSQL’ 指代基本的关系数据库功能，而 ‘PostGIS’ 指代扩展的空间 *** 作特性。

客户端－服务器构架

PostgreSQL 同众多数据库产品一样，采用客户端－服务器构架。客户端向服务器发出请求并得到响应。这种机制同浏览器从网络服务器获取网页类似。在 PostgreSQL 中，请求以 SQL 语言发出，而响应多为从数据库提取的表单。

客户端与服务器可以部署在同一台设备上，即 PostgreSQL 可以在单一的计算机上使用。借由系统内部的 ‘loopback’ 通信机制，数据库系统可以进行私密通讯。除非专门配置，外界是不能访问这些信息的。

本位介绍三种客户端：命令行， Quantum GIS ， pgAdmin 图形化数据库客户端。

创造具有空间信息处理能力的数据库

命令行客户端在终端模拟器（Terminal Emulator）中运行。在 Applications 菜单的 Accessories 中打开一个终端模拟器，将显示一个 Unix 风格的命令行界面。输入：

psql -V

回车确认，将显示 PostgreSQL 版本号。

一个 PostgreSQL 服务器中，可以将不同的任务组织到不同的数据库。每个数据库独立运作，拥有专门的表单、显示、用户等。访问 PostgreSQL 数据库时将指定一个数据库。

服务器上数据库列表通过以下命令查询：

psql -l

输出将罗列 Live 上配置的几个数据库。这里演示新建一个。

PostgreSQL 使用 createdb 工具创建数据库。这里建立的数据库应带有 PostGIS 的扩展功能，因此需要指定相应的模板。这里将新建数据库称为 demo 。命令为：

createdb-Ttemplate_postgisdemo

现在执行 psql-l 应当可以看到 demo 数据库。

也可以使用 SQL 语言创建 PostGIS 数据库。首先使用 dropdb 命令删除之前创建的数据库，然后使用 psql 命令开启 SQL 命令解析器：

dropdbdemopsql-dpostgres

这样就连接到了一个通用的系统数据库 postgres 。输入 SQL 命令建立新数据库：

postgres=# CREATE DATABASE demo TEMPLATE=template_postgis;

现在可以转换连接到新建的数据库。若重新连接时可以使用 psql-ddemo 命令。但在 psql 系统内部也可以使用以下命令：

postgres=# \c demo

一个信息页面将显示当前已连接 demo 数据库。输入 \dt 列出当前数据库内的表单，输出如下：

demo=# \dtListofrelationsSchema|Name|Type|Owner--------+------------------+-------+-------public|geometry_columns|table|userpublic|spatial_ref_sys|table|user(2rows)

这两个表格是 PostGIS 默认的。其中 spatial_ref_sys 存储着合法的空间坐标系统。利用 SQL 查询查看：

demo=# SELECT srid,auth_name,proj4text FROM spatial_ref_sys LIMIT 10;srid|auth_name|proj4text------+-----------+--------------------------------------3819|EPSG|+proj=longlat+ellps=bessel+towgs3821|EPSG|+proj=longlat+ellps=aust_SA+no_d3824|EPSG|+proj=longlat+ellps=GRS80+towgs83889|EPSG|+proj=longlat+ellps=GRS80+towgs83906|EPSG|+proj=longlat+ellps=bessel+no_de4001|EPSG|+proj=longlat+ellps=airy+no_defs4002|EPSG|+proj=longlat+a=6377340189+b=634003|EPSG|+proj=longlat+ellps=aust_SA+no_d4004|EPSG|+proj=longlat+ellps=bessel+no_de4005|EPSG|+proj=longlat+a=6377492018+b=63(10rows)

以上显示确认了该数据库已经建立空间 *** 作功能。数据库中的 geometry_columns 用于记录那些表格是有空间信息的。

手工建立空间数据表格

空间数据库已经建立，现在可以建立具有空间信息的表格。

首先建立一个常规的表格存储有关城市（cities）的信息。这个表格有两栏，一个是 ID 编号，一个是城市名：

demo=# CREATE TABLE cities ( id int4, name varchar(50) );

现在添加一个空间栏用于存储城市的位置。习惯上这个栏目叫做 the_geom 。它记录了数据为什么类型（点、线、面）、有几维（这里是二维）以及空间坐标系统。此处使用 EPSG:4326 坐标系统：

demo=# SELECT AddGeometryColumn ('cities', 'the_geom', 4326, 'POINT', 2);

完成后，查询 cities 表单应当显示这个新栏目。同时页面将显示当前表达没有记录（0 rows）。

demo=# SELECT from cities;id|name|the_geom----+------+----------(0rows)

为添加记录，需要使用 SQL 命令。对于空间栏，使用 PostGIS 的 ST_GeomFromText 可以将文本转化为坐标与参考系号的记录：

demo=# INSERT INTO cities (id, the_geom, name) VALUES (1,ST_GeomFromText('POINT(-01257 51508)',4326),'London, England');demo=# INSERT INTO cities (id, the_geom, name) VALUES (2,ST_GeomFromText('POINT(-81233 42983)',4326),'London, Ontario');demo=# INSERT INTO cities (id, the_geom, name) VALUES (3,ST_GeomFromText('POINT(2791162491 -3301529)',4326),'East London,SA');

当然，这样的输入方式难以 *** 作。其它方式可以更快的输入数据。就目前来说，表格内已经有了一些城市数据，可以先进行查询等 *** 作。

简单查询

标准的 SQL *** 作都可以用于 PostGIS 表单：

demo=# SELECT FROM cities;id|name|the_geom----+-----------------+----------------------------------------------------1|London,England|0101000020E6100000BBB88D06F016C0BF1B2FDD2406C149402|London,Ontario|0101000020E6100000F4FDD478E94E54C0E7FBA9F1D27D45403|EastLondon,SA|0101000020E610000040AB064060E93B4059FAD005F58140C0(3rows)

这里的坐标是无法阅读的 16 进制格式。要以 WKT 文本显示，使用 ST_AsText(the_geom) 或 ST_AsEwkt(the_geom) 函数。也可以使用 ST_X(the_geom) 和 ST_Y(the_geom) 显示一个维度的坐标：

demo=# SELECT id, ST_AsText(the_geom), ST_AsEwkt(the_geom), ST_X(the_geom), ST_Y(the_geom) FROM cities;id|st_astext|st_asewkt|st_x|st_y----+------------------------------+----------------------------------------+-------------+-----------1|POINT(-0125751508)|SRID=4326;POINT(-0125751508)|-01257|515082|POINT(-8123342983)|SRID=4326;POINT(-8123342983)|-81233|429833|POINT(2791162491-3301529)|SRID=4326;POINT(2791162491-3301529)|2791162491|-3301529(3rows)

空间查询：

PostGIS 为 PostgreSQL 扩展了许多空间 *** 作功能。以上已经涉及了转换空间坐标格式的 ST_GeomFromText 。多数空间 *** 作以 ST（spatial type）开头，在 PostGIS 文档相应章节有罗列。这里回答一个具体的问题：以米为单位并假设地球是完美椭球，上面三个城市相互的距离是多少？

demo=# SELECT p1name,p2name,ST_Distance_Sphere(p1the_geom,p2the_geom) FROM cities AS p1, cities AS p2 WHERE p1id > p2id;name|name|st_distance_sphere-----------------+-----------------+--------------------London,Ontario|London,England|587576685191657EastLondon,SA|London,England|978964696784908EastLondon,SA|London,Ontario|138921609525778(3rows)

输出显示了距离数据。注意 ‘WHERE’ 部分防止了输出城市到自身的距离（0）或者两个城市不同排列的距离数据（London, England 到 London, Ontario 和 London, Ontario 到 London, England 的距离是一样的）。尝试取消 ‘WHERE’ 并查看结果。

这里采取不同的椭球参数（椭球体名、半主轴长、扁率）计算：

demo=# SELECT p1name,p2name,ST_Distance_Spheroid(p1the_geom,p2the_geom,'SPHEROID["GRS_1980",6378137,298257222]')FROMcitiesASp1,citiesASp2WHEREp1id>p2id;name|name|st_distance_spheroid-----------------+-----------------+----------------------London,Ontario|London,England|589241363776489EastLondon,SA|London,England|975684265711931EastLondon,SA|London,Ontario|138841494140698(3rows)

制图

以 PostGIS 数据制图需要相应的客户端支持。包括 Quantum GIS、gvSIG、uDig 在内的多种客户端均可以。以下使用 Quantum GIS：

从 Desktop GIS 菜单启动 Quantum GIS 并在其 layer 菜单选择 AddPostGISlayers 。连接到 Natural Earth PostGIS 数据库的参数在 Connections 下拉菜单中有。这里可以定义和储存其它的配置。点击 Edit 可以查看具体参数。点击 Connect 连接：



系统将显示所有空间信息表供选择：



选择 lakes 湖泊表单并点击底部的 Add 添加。顶部的 Load 可以载入新的数据库连接配置。数据将被导入：



界面上显示出湖泊的分布。QGIS 并不理解湖泊一词的含义，也许不会自动使用蓝色。请查看其手册了解如何设置。这里缩放到加拿大一处著名的湖泊群。

自动创建空间数据表单

OSGeo Live 的多数桌面 GIS 系统都可以将 shp 等文件导入数据库。这里依然使用 QGIS 演示。

QGIS 中导入 shp 可以使用 PostGIS Manager 插件。在 Plugins 菜单选择 FetchPlugins 导入最新的官方插件列表（需要网络连接）。找到 PostGISManager 点击 Installplugin 安装。



完成后，在 Plugin 菜单点击 PostGIS Manager 启动。也可以点击工具栏上大象与地球的图标。

该插件将连接 Natural Earth 数据库。若提示输入密码，留空即可。在开启的界面中，选择表单可以显示相应的信息。预览（Preview）选项卡可以显示地图预览。这里选择了 populated places 图层并缩放到一个小岛：



接下来使用 PostGIS Manager 将 shp 导入数据库。这里使用 R 统计扩展包含的 North Carolina sudden infant death syndrome (SIDS) 数据：

在 Data 菜单选择 Loaddatafromshapefile 选项。点击 选中 R maptools 中的 sidsshp 。

select pg_constraintconname as pk_name from pg_constraint inner join pg_class

on pg_constraintconrelid = pg_classoid where pg_classrelname = 'yourtablename' and pg_constraintcontype='p'

这个可以显示yourtablename表的主键

select pg_constraintconname as pk_name,pg_attributeattname as colname,pg_typetypname as typename from

pg_constraint inner join pg_class

on pg_constraintconrelid = pg_classoid

inner join pg_attribute on pg_attributeattrelid = pg_classoid

and pg_attributeattnum = pg_constraintconkey[1]

inner join pg_type on pg_typeoid = pg_attributeatttypid

where pg_classrelname = 'yourtablename'

and pg_constraintcontype='p'

这个可以显示出主键名，和主键关联的字段名,和字段名类型

以上就是关于PostgreSQL的NoSQL特性全部的内容，包括:PostgreSQL的NoSQL特性、求asp连接postgresql数据库的具体方法、如何提高postgresql查询性能等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！