新系統的數據庫設計，但遺留依賴

我們計劃在PHP（Symfony 2）和PostgreSQL中創建一個Web應用程序的新項目（完全重新啓動）。目前我們使用PHP和MySQL（MyISAM）。 - > webapp新系統的數據庫設計，但遺留依賴

當前和新的webapp取決於包括數據庫（MS SQL 8/2000）在內的另一個系統（.NET），因爲它不會很快被修改（更改或合併數據庫）有與整個megillah 一個複雜的工作流 - >遺留系統
BTW：最大的表有27萬行總

大部分數據/表將轉移每天 multuple時間從原有數據庫到webapp數據庫。對於新的Web應用程序，我們已經重新設計了大部分的數據庫架構的，所以我們現在幾乎規範化模式（傳統數據庫的模式是大量多餘的，真的很亂）

目前轉移工作嘗試插入數據。當特定代碼出現異常時，我們知道該行已經存在，然後執行更新。這是因爲性能（更新前沒有選擇）。

對於新的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 將被轉換爲，所以長度是原來的兩倍。另一個例子123A9 - > 。因爲每個字符都有兩位數字，所以它也可以被轉換回來。

我的第一個疑問是稀疏的PK會帶來一些性能問題，但是當使用b-tree（self-balancing）作爲Postgres默認索引系統的索引時，它應該沒問題。

您認爲如何？您是否有過使用遺留依賴項的類似系統的經驗？

來源

2012-10-25 timaschew

'123456P32'的轉換超出整數的範圍。 –

我不確定是否有這樣的PK，但對於這種情況我們可以使用bigint。明天我會精確地分析這些列。 – timaschew

PostgreSQL與文本PK的表現並不差 - 爲了簡單起見，我會用它。
您沒有告訴我們這些密鑰可以使用多久。使用你的轉換一個普通的整數就足夠了，只有4個字符的鍵和bigint只有9個。

來源

2012-10-25 15:54:59 Tometzky

使用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比大多數人意識到。

來源

2012-10-25 16:11:04

新系統的數據庫設計，但遺留依賴

回答

相關問題