desain basis data untuk sistem baru tetapi ketergantungan lama

Kami berencana membuat proyek baru (peluncuran ulang lengkap) aplikasi web dalam PHP (Symfony 2) dan PostgreSQL. Saat ini kami menggunakan PHP dan MySQL (MyISAM). -> aplikasi web

Webapp saat ini dan yang baru bergantung pada sistem lain (.NET) termasuk database (MS SQL 8/2000), yang tidak akan dimodifikasi (mengubah atau menggabungkan database bersama-sama) dalam waktu dekat, karena ada alur kerja yang kompleks dengan keseluruhan megillah -> sistem lama
BTW: tabel terbesar memiliki total 27 juta baris

Sebagian besar data/tabel akan ditransfer beberapa kali per hari dari database lama ke database webapp. Untuk aplikasi web baru, kami telah mendesain ulang sebagian besar skema basis data, jadi sekarang kami memiliki skema yang hampir dinormalisasi (skema basis data lama sangat mubazir dan sangat berantakan)

Saat ini tugas transfer mencoba memasukkan data. Ketika ada pengecualian dengan kode tertentu, kita mengetahui baris tersebut sudah ada dan kemudian melakukan pembaruan. Ini karena kinerja (tidak ada pilihan sebelum pembaruan).

Untuk skema webapp baru kami masih ingin menggunakan ID utama yang sama seperti di database lama. Namun ada beberapa masalah, salah satunya: beberapa tabel memiliki kunci utama yang terlihat seperti bilangan bulat, padahal sebenarnya tidak. sebagian besar baris memiliki bilangan bulat seperti 123456, tetapi ada beberapa baris dengan karakter seperti 123456P32.

Sekarang ada dua opsi untuk skema baru:

  1. Gunakan tipe string untuk PK dan risiko masalah kinerja

  2. Gunakan tipe integer untuk PK dan lakukan konversi. Konversinya akan terlihat seperti ini (berbasis karakter)

    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 lama 123 akan diubah menjadi 111213, sehingga panjangnya menjadi dua kali lipat dari aslinya. Contoh lain 123A9 -> 1112135019. Karena setiap karakter memiliki dua digit maka juga dapat dikonversi kembali.

Keraguan pertama saya adalah bahwa PK yang jarang akan membawa beberapa masalah kinerja, tetapi ketika menggunakan b-tree (self-balancing) sebagai indeks yang merupakan sistem indeks default untuk Postgres, itu akan baik-baik saja.

Bagaimana menurutmu? Apakah Anda punya pengalaman dengan sistem serupa dengan ketergantungan lama?


postgresql database-design legacy
person timaschew    schedule 25.10.2012    source sumber
comment
Konversi 123456P32 berada di luar jangkauan bilangan bulat.   -  person Clodoaldo Neto    schedule 25.10.2012
comment
Saya tidak yakin apakah ada pk seperti ini, tapi untuk kasus ini kita bisa menggunakan bigint. Besok saya akan menganalisis kolom-kolomnya dengan tepat.   -  person timaschew    schedule 25.10.2012

Jawaban (2)


arrow_upward
1
arrow_downward

  • Performa PostgreSQL dengan PK teks tidak terlalu buruk — saya akan menggunakannya demi kesederhanaan.

  • Anda tidak memberi tahu kami berapa panjang kunci ini. Menggunakan konversi Anda, bilangan bulat biasa hanya cukup untuk 4 karakter kunci dan bigint hanya untuk 9.

person Tometzky    schedule 25.10.2012

arrow_upward
1
arrow_downward

Gunakan CREATE DOMAIN untuk mengisolasi tipe data yang diusulkan. Kemudian buat dan uji prototipe. Anda beruntung; Anda tidak kekurangan data pengujian yang valid.

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.
);

Untuk menguji database kedua menggunakan kunci bilangan bulat, buang skemanya, ubah satu baris tersebut (dan nama database jika Anda ingin memiliki keduanya secara bersamaan), dan muat ulang.

create domain legacy_key as bigint not null;

Anda harus berpikir keras untuk menyimpan kunci utama sistem lama sebagaimana adanya. Tidak ada yang perlu di-debug--pikiran sangat tenang. Jika Anda harus mengonversi, berhati-hatilah dengan nilai seperti '1234P45'. Jika huruf tersebut adalah E atau D, beberapa aplikasi akan menafsirkannya sebagai indikasi eksponen.

Anda seharusnya tidak mengalami masalah kinerja karena panjang kunci jika Anda menggunakan kunci varchar() yang terdiri dari 10 atau 15 karakter, terutama dengan versi 9.2. Baca dokumentasi tentang indeks sebelum Anda mulai. PostgreSQL mendukung lebih banyak jenis indeks daripada yang disadari kebanyakan orang.

person Mike Sherrill 'Cat Recall'    schedule 25.10.2012