相关疑难解决方法(0)

我遇到了我的主键序列与我的表行不同步的问题.

也就是说,当我插入一个新行时,我得到一个重复的键错误,因为串行数据类型中隐含的序列返回一个已经存在的数字.

这似乎是由导入/恢复不能正确维护序列引起的.

我的问题很简单.我知道UUID的概念,我想生成一个从我的DB中的'store'引用每个'item'.看似合理吧？

问题是以下行返回错误:

honeydb=# insert into items values(
uuid_generate_v4(), 54.321, 31, 'desc 1', 31.94);
ERROR:  function uuid_generate_v4() does not exist
LINE 2: uuid_generate_v4(), 54.321, 31, 'desc 1', 31.94);
        ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.

我已经阅读了以下网页:http://www.postgresql.org/docs/current/static/uuid-ossp.html

我在Ubuntu 10.04 x64上运行Postgres 8.4.

使用Postgres,我试图AUTO_INCREMENT在SQL中自动编号我的主键.但是,它给了我一个错误.

CREATE TABLE Staff   (
  ID        INTEGER NOT NULL AUTO_INCREMENT,
  Name      VARCHAR(40) NOT NULL,
  PRIMARY KEY (ID)
);

错误:

********** Error **********
ERROR: syntax error at or near "AUTO_INCREMENT"
SQL state: 42601
Character: 63

Run Code Online (Sandbox Code Playgroud)

知道为什么吗？

我们当前的PostgreSQL数据库使用GUID作为主键并将它们存储为Text字段.

我对此的初步反应是,尝试执行任何类型的最小笛卡尔联接都是索引的噩梦,试图找到所有匹配的记录.但是,也许我对数据库索引的有限理解在这里是错误的.

我认为我们应该使用UUID,因为它们存储为GUID的二进制表示,其中Text不是,并且您在Text列上获得的索引量是最小的.

改变这些将是一个重要的项目,我想知道它是否值得吗？

我正在尝试维护一个地址历史表:

CREATE TABLE address_history (
    person_id int, 
    sequence int,
    timestamp datetime default current_timestamp,
    address text,
    original_address text,
    previous_address text,
    PRIMARY KEY(person_id, sequence),
    FOREIGN KEY(person_id) REFERENCES people.id
);

我想知道是否有一种简单的方法可以自动编号/约束sequence,address_history从而自动从1开始计数person_id.

换句话说,第一行person_id = 1会得到sequence = 1; person_id = 1会得到第二排sequence = 2.第一行person_id = 2,将sequence = 1再次获得.等等.
还有更好/内置的方式来维护这样的历史吗？

我有一个 django 模型，它的 id 开始奇怪地增加。

列的 postgres 定义（从 Django 模型生成）：

id | integer | not null default nextval('billing_invoice_id_seq'::regclass)

tpg=> SELECT MAX(id) FROM billing_invoice;
  max  
-------
 16260

然后我通过 django admin 创建了一个新记录：

tpg=> SELECT MAX(id) FROM billing_invoice;
  max  
-------
 17223

tpg=> SELECT nextval('billing_invoice_id_seq');
 nextval 
---------
   17224

然后我创建了一个新记录，它跳过了 17224 值并插入了 17225 的主键：

tpg=> SELECT nextval('billing_invoice_id_seq');
 nextval 
---------
   17226

有谁知道为什么会这样？应用程序此时并不关心，因为 id 仍在增加，但在最后几个新对象中，PK 在一次插入中从 427 -> 4357 跳过，然后在 2 个对象中跳到 8378，然后在 3 个对象中跳到 97xx它跳到了 14k。