Question

我们计划在PHP（Symfony 2）和PostgreSQL中创建一个Web应用程序的新项目（完全重新启动）。目前我们使用PHP和MySQL（MyISAM）。的 - ＆GT; web应用

当前和新的webapp依赖于另一个系统（.NET），包括一个数据库（MS SQL 8/2000），不会很快修改（更改或合并数据库），因为有一个复杂的工作流程整个megillah - ＆gt;遗留系统
顺便说一句：最大的表总共有2700万行

从遗留数据库到webapp数据库，大多数数据/表每天都会传输多次。对于新的webapp，我们已经重新设计了大部分数据库模式，因此我们现在几乎已经规范化了模式（遗留数据库的模式是大量冗余而且非常混乱）

目前转移作业尝试插入数据。当特定代码出现异常时，我们知道该行已存在，然后执行更新。这是因为性能（更新前没有选择）。

对于新的webapp架构，我们仍然希望使用与旧数据库中相同的主ID。但是有一些问题，其中之一：一些表的主键看起来像一个整数，但它们不是。大多数行都有123456之类的整数，但是，有些行的字符如123456P32。

现在新架构有两个选项：

将字符串类型用于PK和风险绩效问题

对PK使用整数类型并进行转换转换可能看起来像这样（基于字符）

legacy      new
--------------------------
0           10
1           11
2           12
.           ..
9           19
a           20
b           21
.           ..
y           45    
z           46
A           50 (not 47, because the arity of the second digit is 'clean' with 50)
B           51
.           ..
Z           76

旧版pk 123 将转换为 111213 ，因此长度是原始版本的两倍。另一个例子 123A9 - ＆gt;的 1112135019 即可。因为每个角色都有两个数字，所以它也可以被转换回来。

我的第一个怀疑是稀疏的PK会带来一些性能问题，但是当使用b-tree（自我平衡）作为Postgres的默认索引sysetm作为索引时，它应该没问题。

Answer 1

使用文本PK的PostgreSQL性能并不是那么糟糕 - 为了简单起见，我会选择它。
您没有告诉我们这些密钥可以使用多长时间。使用你的转换，普通的整数就足够只有4个字符的密钥而bigint仅适用于9个。

Answer 2

使用CREATE DOMAIN隔离建议的数据类型。然后构建并测试原型。你很幸运;你不缺少有效的测试数据。

create domain legacy_key as varchar(15) not null;

create table your_first_table (
  new_key_name legacy_key primary key,
  -- other columns go here.
);

要使用整数键测试第二个数据库，请转储架构，更改一行（如果要同时使用这两个数据库，则更改数据库的名称），然后重新加载。

create domain legacy_key as bigint not null;

您应该认真考虑将旧系统的主键完全按原样存储。无需调试 - 让您高枕无忧。如果必须转换，请注意“1234P45”等值。如果该字母恰好是 E 或 D ，则某些应用程序会将其解释为指示指数。

如果您使用的是10或15个字符的varchar（）键，尤其是版本9.2，则不会因密钥长度而导致性能问题。在开始之前阅读有关索引的文档。 PostgreSQL supports more kinds of indexes比大多数人都意识到的那样。

新系统的数据库设计，但遗留依赖

2 个答案: