DB กับ RPG
ในความเป็นจริง
บริษัทต่างๆ ที่เปิดตัวมานานเกิน
10 ปี ต้องมีการวางโครงสร้าง DB ไว้แล้ว
หน้าที่ของเราคือ เข้าใจ + ใช้ "สิ่งที่มีอยู่" ให้ดี (มาเดาใจ คนออกแบบเดิม กันดีกว่า)
ความสะดวกสบายจาก สิ่งที่เรียนจบมาใหม่ๆ
ทยอยเก็บใส่ลิ้นชักไปได้เลย
กรณีที่ RPG รุ่นใหม่ สามารถ "ข้าม" ข้อจำกัดได้หลายเรื่อง
แต่ถ้าคุณต้องทำงานกับทีมงานที่คุ้นเคย RPG รุ่นก่อน จะเขียนด้วยเทคนิคใหม่ทั้งหมด คงไม่เหมาะ
สุดท้าย ก็คงต้องหลิ่วตาตามน๊ะครับ : )
แต่ถ้าคุณต้องทำงานกับทีมงานที่คุ้นเคย RPG รุ่นก่อน จะเขียนด้วยเทคนิคใหม่ทั้งหมด คงไม่เหมาะ
สุดท้าย ก็คงต้องหลิ่วตาตามน๊ะครับ : )
ทบทวน การออกแบบ DB (แบบย่อ)
0. เตรียม ข้อมูลที่ต้องการออกแบบ (ส่วนใหญ่ ที่ชัดเจนมักจะเป็น เอกสาร)เช่น เอกสารซื้อ,ขาย (งานขาย,บัญชี), คลังสินค้า เป็นต้น
Tip จัดตามแผนกฯ,หน้าที่ หรือ จัดตาม S/W ทั่วไป เช่น เอกสารซื้อ,ขาย (งานขาย,บัญชี), คลังสินค้า เป็นต้น Tip จัดตามแผนกฯ,หน้าที่ หรือ จัดตาม S/W ทั่วไป1. เปลี่ยนเป็น "แนวคิด" (Logical) จะได้ รูปภาพ (ER) แสดง "กฏ" = คุณลักษณะ และ Relation เช่น 1 อินวอยซ์ มีได้หลายรายการสินค้า หรือ Fix มีแค่ 1 รายการเท่านั้น (1:m หรือ 1:1) Tip ถ้าผู้ออกแบบ คุ้นเคย หรือ ใช้งานเอกสารนั้น ก็จะรู้ "กฏ" ทางธุรกิจนั้นๆ2. นำ "แนวคิด" ไป สร้าง DB จริง (Physical) ตาม DB ที่เราเลือกใช้
เช่น
เช่น ใน DB2/400 สร้าง Physical File(Table) ใน QDDSSRC แล้วสั่ง Create เป็นต้น
ตย. การบันทึก ในแบบ Form ของIBM (ง่ายดี) - ปัจจุบัน มีบางคนยังใช้งานอยู่
ตย. การบันทึก ใน Editor (STRSEQ) ของ IBM
การสร้าง DB ในปัจจุบัน จะถูกแยกการออกแบบ ออกไปอย่างอิสระ(ดี)
- การเขียนโปรแกรม
จึงเพียงแค่ไปอ่านสเปคของ DB
แต่ภาษา RPG เป็นภาษาที่มีอายุ(เก่า)และ มีข้อจำกัดพอสมควร ทำให้การออกแบบ DB เพื่อใช้งานกับ RPG ต้องรู้ข้อจำกัดดังกล่าวด้วย ในที่นี่ จะทยอยพูดไปเรื่อยๆ (เหมาะกับ คนที่เคยใช้มาบ้าง)
ตย.เช่น เขียนในรุ่นก่อน
RPG/400
- ชื่อ Field ที่ต้องมีขนาดไม่เกิน 6 อักษร
- ชื่อ File ต้องยาวไม่เกิน 8 อักษร (นับอักษรในช่องที่แสดง)
Table (File) : CUSTOMER_REGISTER,ชื่อ Field=CUSTOMER_ID … ชื่อยาวเกิน 6 อักษร
Table (File) : INVOCE_HEAD,
INVOICE_DETAIL, INVOICE_CONFIRM … ชื่อยาวเกิน 8 อักษร และเป็นกลุ่ม
เมื่อเขียนด้วย SQL – DB Engine จะไปเลือก Index
File ที่เหมาะสมให้ (อาจจะเลือกผิดก็ได้) แต่ใน RPG เราจะเลือกไปเลย (ไม่ผิดแน่)
>> ต้องตั้งชื่อ แบบนี้ INV010p,
INV020p,INV030p หรือ INV010L2,INV020L5
(p) ในที่นี้เป็นการเรียกใช้ Physical
Table (ไม่มี Index)
(L2,L5) คือ Index File ที่เราตั้งใจเลือก
Table (File) : CUSTOMER และ VENDOR มี Field=NAME เหมือนกัน …
การอ้างอิงใน SQL จะเขียนแบบนี้ CUSTOMER.NAME
หรือ VENDOR.NAME … ชื่อยาวเกิน 8 อักษร
>>
ต้องพยายามตั้งชื่อให้ ใช้ต่างกัน เช่น CUSTOMER
ใช้รหัส C1NAME, VENDOR ใช้ V5NAME
- เมื่อ Compile
RPG จะจัดเก็บโครงสร้าง Table (File) ไว้ใน Object
ของ RPG (เห็น DB Info ในตัว RPG) … ถ้าใครเปลี่ยนโครงสร้าง DB RPG จะตรวจพบว่า ไม่เหมือนกันแล้วมันจะ
“หยุด” ทำงาน -> ต้อง re-compile ใหม่ (เสียเวลา ชัดเจนถ้ามีโปรแกรมมากกว่า 100 ตัวที่เรียกใช้)
>> หลีกเลี่ยงการเปลี่ยน Design File/Field บ่อยๆ (เทคนิค ทำไป/ออกแบบไป)
การออกแบบ DB
-ต้องทำ Data Dictionary ก่อน! ในวิชา DB มีพูดถึง มักใช้ออกแบบกับระบบขนาดใหญ่ ใช้ป้องกัน
การตั้งชื่อ (Field,Table) ที่อาจจะ “สับสน” เช่น Date -> InvoiceDate -> EntryDate, ModifyDate ตอนเรียนจะทำระบบขนาดเล็ก ทำให้ไม่เกิดปัญหา และไม่ต้องทำส่วนนี้
ตย. 1 Data Dictionary การตั้งชื่อ Table (File) Physical และ Field
ข้อจำกัดใน RPG ก่อน RPG/400 ชื่อ File ต้องยาวไม่เกิน 6 อักษร)
|
กลุ่ม
|
Name
|
File ID
|
Field Begin Code
|
|
Customer
|
Customer
|
CST010p
|
C1
|
|
|
..
|
|
|
|
Invoice
|
Invoice_Head
|
INV010p
|
I1
|
|
|
Invoice_Detail
|
INVO20p
|
I2
|
|
|
Invoice_Confirm
|
INV030p
|
I3
|
|
Stock
|
…
|
|
|
|
|
|
|
|
|
Stock-Inventory
|
Inventory_Tag
|
STK0A0p
|
SA
|
|
|
Inventory_Void
|
STK0B0p
|
SB
|
Tip : บางที่จัดเก็บ Field Begin Code เป็น 1 Field เป็น Field แรกไว้ใน Table(File) เลย
ข้อดี – ดูที่ Raw Data ก็จะเห็น Field Begin Code (ไม่ต้องมาเขียนในสมุด)
ข้อเสีย – เพิ่ม “กฏ” Field ดังกล่าวต้องมีค่าดังกล่าว (ประกาศ
ตอนสร้าง DB หรือ ระบุในโปรแกรมบันทึก)
ตอนผมไปดูงานที่บริษัทแม่ (ญี่ปุ่น) เขาเปิดสมุดบันทีกในแบบข้างบน ให้ดู
(ตกใจกันหน่อยครับ "สมุดบันทึก" นี้อายุเกิน 15 ปีแล้ว)
(ตกใจกันหน่อยครับ "สมุดบันทึก" นี้อายุเกิน 15 ปีแล้ว)
ตย. 2 Data Dictionary ระดับ File/Field
ข้อจำกัดใน RPG ก่อน RPG/400 ชื่อ Field ต้องยาวไม่เกิน 6 อักษร)
|
กลุ่ม
|
Invoice
|
|
|
File ID
|
INV010P
|
Invoice_Head
|
|
Field ID
|
|
|
|
Field Description
|
|
I1IVNO
|
PK
|
String
|
10
|
Invoice No
|
|
I1IVYY
|
|
Int
|
4
|
Invoice Year
|
|
I1IVMM
|
|
Int
|
2
|
Invoice Month
|
|
I1CSCD
|
|
String
|
10
|
Customer Code
|
|
|
FK
|
|
|
C1CSCD (CST010p)
|
|
I1AMT
|
|
Long
|
11,0
|
Amount
|
สังเกต ต้องทำ ตย.1 มาก่อน จะทำให้ทำงานง่าย
ตย. 3 Data Dictionary การตั้งชื่อ Table (File) Index (Logical)
|
กลุ่ม
|
Name
|
File ID
|
Index Field
|
|
Customer
|
..
|
|
|
|
|
..
|
|
|
|
Invoice
|
Invoice_Head
|
INV010L1
|
I1IVNO(Invoice No)
|
|
|
|
INV010L2
|
I1IVYY (Invoice Year),I1IVMM,1IVNO
|
|
|
|
|
|
|
|
Invoice_Detail
|
INVO20L1
|
I2IVNO,I2SEQ
|
|
|
|
INV020L2
|
I2IVNO,I2ITNO(item No)
|
|
|
|
|
|
Tip : บริษัท ควรจะสร้างเครื่องมือ ที่แสดงผลลัพธ์ คล้ายแบบข้างต้นไว้ (ไม่ต้องมาเขียนในสมุด)
แต่ต้องรู้ CL Cmd ด้วย ที่บริษัทฯ ผมมีคนสร้างไว้ให้ใช้ : )
สรุป จากข้อจำกัด ทำให้ต้องมีการสร้าง "กฏ" ขึ้นเองในลักษณะนี้
Table (File) - XYZnnnP, XYZnnnLN หริอ ABnnnP, ABnnnLN หรือ ABXYZnP, ABXYZnN
AB, XYZ, ABXYZ เป็นรหัสกลุ่ม เช่น SL (Sale), INV (Invoice), SLINV
nnn,n เป็นเลขที่ 001,002, 010,020, 1-9,A-Z
P บอกให้รู้ว่าเป็น Physical
LN,N บอกให้รู้ว่าเป็น Index (Logical)
บริษัทที่ทำงานงานอยู่ เลือกใช้แบบไหน ?
ตอนนี้หลายท่านคงทราบแล้วว่า ทำไมตั้งชื่อตลก,แปลก
Share : ผู้เขียนได้ไปดูการชื่อ Table ใน SAP พบว่ามาในแนวเดียวกัน ถ้าใครเห็นแนวทาง ก็ต้องไปหา Data Dictionary มาดูประกอบด้วย
สำหรับน้องใหม่ ลองสร้างหลายแบบดู จะเห็นข้อดี/ด้อย ของแต่ละแบบ
(ฝึกไว้ เวลาไปออกแบบ CMS ก็จะพบปัญหาคล้ายกัน)
ขออภัย สำหรับบางท่านที่อยากจะให้สรุป หรือ อธิบายเป็นกฏ ตามหนังสือ
ผู้เขียนแนะนำให้ ไปอ่านหนังสือโดยตรงดีกว่าครับ ลองค้น IBM Red Book
ถ้าเขียนตามหนังสือ กว่าจะเริ่มสร้างได้จริง ต้องอ่าน 2-3 เล่ม (มีรายละเอียด + แตกย่อยไปมาก)
เนื้อหา จะมีมาก (จนคนรุ่นใหม่ จะรู้สึกท้อ เมื่อต้องมาเรียนรู้สิ่งที่มากและยาก)
