การออกแบบฐานข้อมูลสำหรับระบบใหม่แต่อาศัยการพึ่งพาแบบเดิม

เรากำลังวางแผนที่จะสร้างโปรเจ็กต์ใหม่ (การเปิดตัวใหม่ทั้งหมด) ของเว็บแอปพลิเคชันใน PHP (Symfony 2) และ PostgreSQL ปัจจุบันเราใช้ PHP และ MySQL (MyISAM) -> เว็บแอป

เว็บแอปปัจจุบันและใหม่ขึ้นอยู่กับระบบอื่น (.NET) รวมถึงฐานข้อมูล (MS SQL 8 / 2000) ซึ่งจะไม่ได้รับการแก้ไข (เปลี่ยนแปลงหรือรวมฐานข้อมูลเข้าด้วยกัน) ในเร็ว ๆ นี้ เนื่องจากมีขั้นตอนการทำงานที่ซับซ้อนกับเมจิลลาห์ทั้งหมด -> ระบบเดิม
BTW: ตารางที่ใหญ่ที่สุดมีทั้งหมด 27 ล้านแถว

ข้อมูล/ตารางส่วนใหญ่จะถูกถ่ายโอนหลายครั้งต่อวันจากฐานข้อมูลเดิมไปยังฐานข้อมูล webapp สำหรับเว็บแอปใหม่ เราได้ออกแบบสคีมาฐานข้อมูลส่วนใหญ่ใหม่แล้ว ดังนั้นเราจึงมีสคีมาเกือบเป็นมาตรฐานแล้ว (สคีมาของฐานข้อมูลแบบเดิมนั้นซ้ำซ้อนมากและยุ่งมากจริงๆ)

ขณะนี้งานการถ่ายโอนพยายามแทรกข้อมูล เมื่อมีข้อยกเว้นกับโค้ดเฉพาะ เราจะทราบแถวนั้นอยู่แล้ว จากนั้นจึงอัปเดต นี่เป็นเพราะประสิทธิภาพ (ไม่มีการเลือกก่อนอัพเดต)

สำหรับสคีมา webapp ใหม่ เรายังคงต้องการใช้ ID หลักเดียวกันเหมือนในฐานข้อมูลเดิม แต่มีปัญหาบางประการ หนึ่งในนั้นคือ บางตารางมีคีย์หลักซึ่งดูเหมือนเป็นจำนวนเต็ม แต่กลับไม่มี แถวส่วนใหญ่มีจำนวนเต็มเช่น 123456 แต่ก็มีบางแถวที่มีอักขระเช่น 123456P32

ขณะนี้มีสองตัวเลือกสำหรับสคีมาใหม่:

  1. ใช้ประเภทสตริงสำหรับปัญหา PK และประสิทธิภาพความเสี่ยง

  2. ใช้ประเภทจำนวนเต็มสำหรับ 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 -> 1112135019 เนื่องจากอักขระทุกตัวมีสองหลักจึงสามารถแปลงกลับได้

ข้อสงสัยแรกของฉันคือ PK ที่กระจัดกระจายจะทำให้เกิดปัญหาด้านประสิทธิภาพ แต่เมื่อใช้ b-tree (การปรับสมดุลในตัวเอง) เป็นดัชนีซึ่งเป็นระบบดัชนีเริ่มต้นสำหรับ Postgres ก็ควรจะใช้ได้

คุณคิดอย่างไร? คุณเคยมีประสบการณ์กับระบบที่คล้ายกันซึ่งมีการพึ่งพาแบบเดิมหรือไม่?


postgresql database-design legacy
person timaschew    schedule 25.10.2012    source แหล่งที่มา
comment
การแปลง 123456P32 อยู่นอกช่วงสำหรับจำนวนเต็ม   -  person Clodoaldo Neto    schedule 25.10.2012
comment
ฉันไม่แน่ใจว่ามี pk แบบนี้หรือเปล่า แต่สำหรับกรณีนี้ เราสามารถใช้ bigint ได้ พรุ่งนี้ฉันจะวิเคราะห์คอลัมน์อย่างแน่นอน   -  person timaschew    schedule 25.10.2012

คำตอบ (2)


arrow_upward
1
arrow_downward

  • ประสิทธิภาพของ PostgreSQL พร้อมข้อความ PK ก็ไม่ได้แย่ขนาดนั้น — ฉันจะเลือกใช้มันเพื่อความเรียบง่าย

  • คุณไม่ได้บอกเราว่ากุญแจพวกนี้จะอยู่ได้นานแค่ไหน การใช้การแปลงจำนวนเต็มธรรมดาจะเพียงพอสำหรับคีย์อักขระเพียง 4 ตัวและ bigint สำหรับ 9 เท่านั้น

person Tometzky    schedule 25.10.2012

arrow_upward
1
arrow_downward

ใช้ 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 บางแอปพลิเคชันจะตีความว่าเป็นการระบุเลขชี้กำลัง

คุณไม่ควรมีปัญหาด้านประสิทธิภาพเนื่องจากความยาวของคีย์ หากคุณใช้คีย์ varchar() ที่มีความยาว 10 หรือ 15 อักขระ โดยเฉพาะในเวอร์ชัน 9.2 อ่านเอกสารเกี่ยวกับดัชนีก่อนที่จะเริ่มต้น PostgreSQL รองรับดัชนีประเภทต่างๆ มากมาย มากกว่าที่คนส่วนใหญ่จะตระหนัก

person Mike Sherrill 'Cat Recall'    schedule 25.10.2012