ออกแบบ หน้าจอ

ออกแบบ หน้าจอ (Display File)

นักศึกษาที่จบใหม่ ส่วนใหญ่ จะมีปัญหากับการออกแบบหน้าจอ (Display File)
กับชุดโปรแกรม RPG ที่มีอยู่  ...   อืมส์ ก็มันคนละยุคกันนี่ครับ :P

ไม่เป็นไร   แค่เข้าใจและประยุกต์ให้เหมาะสมก็ทำงานด้วยกันได้ง่ายแล้ว   เอาล่ะมาเริ่มกันเลยครับ

ชนิดของหน้าจอ

ผมแบ่ง  การเรียกใช้โปรแกรม RPG  ออกเป็น   กลุ่มดังนี้

a. ไม่ใช้หน้าจอ เลย  ... อันนี้ไม่พูดถึงน๊ะครับ
    ตย. ที่ใช้บ่อย  คือ  เรียกรายงานแบบ Batch
b. หน้าจอ  โดยไม่ติดต่อกับ DB  ...  มักทำเป็นแบบฝึกหัด
c. ใข้หน้าจอ  ติดต่อ DB ทีละ Record
    c.1 ดูอย่างเดียว
    c.2 add, change, delete Record
d. ใช้หน้าจอ  ติดต่อ DB ทีละหลาย Records  ... รู้จักกันในชื่อ Sub-File

    d.1 ดูอย่างเดียว 

    d.2 add, change, delete Record 

ลองดูภาพ   แล้วเทียบกับที่แต่ละคน  ออกแบบมาน๊ะครับ (เหมือน หรือ แตกต่าง)

หน้าจอ  โดยไม่ติดต่อกับ DB

จากภาพ  มีอะไร ?  ที่แตกต่างจากการออกแบบในยุคนี้ครับ ?

- ไม่ใช้  วิธีคลิก ปุ่ม (Submit) แต่ต้องกด Enter ...  แทบจะไม่ใช้งาน Mouse เลย

- การยกเลิกการใช้   ไม่ใช้ปิด Windows  แต่ต้องกดปุ่ม

   (F1 = ใช้ Function Key แถวบนของ Keyboard)

เทคนิคอื่นๆ 

- มุมบนซ้าย  ใส่ code   "w1","w2"  ใช้บอกสถานะว่า  กำลังใช้  หน้าจอลำดับไหนอยู่

- หน้าจอ  มีคำอธิบายที่ "ชัดเจน" (ไม่ต้องทำคุ่มือการใช้)

- ช่องที่ป้อนข้อมูลได้  จะเห็นเป็น "จุด" (Column Seperate) 

  ช่องไหน ที่ป้อนแล้ว  จะแสดงด้วย  "ตีเส้นใต้" (Underline)

Note   RPG พัฒนามาจากเครื่องมินิคอมพ์พิวเตอร์   
         มี Server ส่วนกลางตัวเดียว รับคำสั่งจาก PC (หรือ workstation) ผ่านการกด Enter  
จะเป็นการดีที่ให้ Server ทำงานน้อยเท่าที่จำเป็น  โดยการออกแบบหน้าจอที่เหมาะสม

หน้าจอ  ติดต่อ DB ทีละ Record

แบบดูผลอย่างเดียว

การออกแบบปัจจุบัน มักจะมี Dropdown รายชื่อพนักงานให้เลือก (ต้องเพิ่ม อ่านข้อมูล มาแสดง)
ตัวหน้าจอ  ต้องทำให้ Dropdown ทำงาน
- ถ้าตัวโปรแกรม  ทำงานบน Server  เท่ากับว่า  "เพิ่มภาระ" ให้ Server
- ถ้าตัวโปรแกรม  ทำงานบน PC ตัวมันเองก็จะดี (เช่น Java Script)

แต่ RPG ทำงานบน Server น๊ะ (ไม่ใช่ PC)  แนวคิดแบบข้างต้น ไม่เหมาะ (Server ต้องทำงานมากเกินไป)

แบบ add, change, delete Record

หน้าจอที่ 1 (w1) ป้อน Employee No  กด Enter

โปรแกรม จะตรวจ  

    ถ้า DB ไม่มีข้อมูล  จะเตรียม  หน้าจอที่ 2 (w2)    จะขึ้นสถานะ "Add" (ภาพแถวบน)

         บันทึกข้อมูล  แล้วกด Enter

              แสดง หน้าจอที่ 3 (w3) เพื่อยืนยัน (confirm)

    ถ้า DB มีข้อมูล  จะ Load ข้อมูล  หน้าจอที่ 2 (w2)    จะขึ้นสถานะ "Change" (ภาพแถวล่าง)

         ปรับ/แก้ไข  แล้วกด Enter

              แสดง หน้าจอที่ 3 (w3) เพื่อยืนยัน (confirm)

ถ้าต้องการ  ออกจากโปรแกรม ให้ กด F1

ถ้าต้องการ  ถอยกลับไปหน้าจอ ก่อนหน้า ให้กด F3

สังเกต  หน้าจอมีลักษณะเหมือนกัน    ในการออกแบบเราสามารถใช้ชุดเดียวกันได้

หน้าจอ  ติดต่อ DB ทีละหลาย Record

หน้าจอ ดูอย่างเดียว

รู้จักกันในชื่อ Sub-File

หน้าจอที่ 1 (w1) ป้อน  Employee No  เพื่อกำหนดจุดแสดงเริ่มต้น เช่น เริ่มต้นที่ B6940
เมื่อกด Enter จะแสดง รายการที่เริ่มต้น
(เทียบกับ .Net ก็คือ GridView)

หน้าจอ  add, change, delete Record 

หน้าจอจะคล้ายกัน  แต่ "เพิ่ม"  ช่องให้เลือกรายการข้อมูลได้
เมื่อเลือกแล้ว หน้าจอจะแสดง  หน้าจอติดต่อกับ DB 1 record
(เทียบกับ .Net ก็คือ GridView แบบแสดงตัวเลือก)

มาถึงจุดนี้  คงเห็นภาพขั้นต้น เพื่อที่จะเขียนโปรแกรมได้แล้วน๊ะครับ
ถัดไป  ก็เขียนโปรแกรม Flow

อืมส์... บางคนคงอึดอัดนิดๆ  เพราะ Developer มักจะคิด "ทุกด้่าน" ในครั้งเดียว
แต่ถ้าเรียงตามลำดับ คือ เราต้องคุ้นกับ "ข้อจำกัด" ก่อน แล้วจึงปรับตัวเลือกตาม

ใช้ Editor SEU

ในการเขียน Source Code Editor พื้นฐานคือ  Source Entry Utility (SEU) 

ข้อสังเกต                วิธีใช้งาน SEU  เหมือนโปรแกรม RW (ราชวิถี เวิร์ด),CW (จุฬา เวิร์ด)   ยุคปี คศ. 198x (20 ปีแล้ว)

ปัจจุบัน มี Editor เฉพาะทางเพิ่มขึ้น

 สำหรับ ผู้ที่ต้องทำงาน  ร่วมกับ ทีมงานเก่า  ควรใช้  SEU ได้คล่องระดับหนึ่ง  ก่อนจะเปลี่ยนไปใช้ Editor เฉพาะ

ขั้นตอนการเขียน Code (แบบย่อ)

1.      จะป้อน Code  เก็บที่ไหน ? ชื่ออะไร ? ชนิดไหน ?  …  Source File,Library, Member, Type

2.      เรียกใช้
2.1 ผ่านตัวจัดการ  strPDM >  3  > ป้อน  Source File,Library, Member, Type
2.2 โดยตรง   STRSEU + [F4] > ป้อน Source File,Library, Member, Type

3.      เริ่มเขียน Code  (ใช้คำสั่งแต่ละพื้นที่)

4.      สิ้นสุดการ เขียน code  โดย กด F3=Exit

ขั้นตอนการเขียน Code (แบบเต็ม)

1.      จะป้อน Code  เก็บที่ไหน ? ชื่ออะไร ? ชนิดไหน ?  …  Source File,Library, Member, Type
Source Code  เรียก “Member”    Member ต้องจัดเก็บอยู่ใน  Library / Source File

*1   RPG/400  (F-spec) ช่อง File Name   ป้อนได้ไม่เกิน 8 อักษร*2   RPG/400  (C-spec) ช่อง Factor 2    จะ call PGM ที่มีชื่อไม่เกิน 8 อักษรเท่านั้น

2.      เรียกใช้  ผ่าน ตัวจัดการ (คล้าย  เลือกชื่อผ่าน Explorer)   …  (แนะนำให้ใช้ตัวนี้)strPDM >  3  > ป้อน  Source File,Library, Member, Type

ป้อนคำสั่ง strpdm + Enter

เลือก 3 + Enter

ป้อน File , Lib  (ตามต้องการ)  Member ใส่ *ALL

ต้องการให้ Member เริ่มแสดงด้วย  Member = SQL  ให้ป้อน Position to (มุมขวาบน)  = SQL 
Tip          สามารถป้อนโดยใช้คำสั่งเดียวดังนี้   wrkmbrpdm qgpl/qddssrc  sql*

3.      เริ่มเขียน Code

3.1  กำหนดค่าเริ่มต้น  ก่อน  กด F13  =Change Session Defaultแนะนำเมื่อกด เลื่อนหน้า ให้เลื่อนทั้งแผ่น (F=Full)

พื้นที่ใช้งาน
(1) คำสั่งจัดการ ภาพรวม

(2) คำสั่งจัดการ กับ “บรรทัด”

(3) ส่วนของ Code

                (1) คำสั่งจัดการ ภาพรวม   … ใช้บ่อย

(9),(10)

                (2) คำสั่งจัดการ กับ “บรรทัด”  … ใช้บ่อย

(3) ส่วนของ Code

3.2  ฝึกป้อน  Code ให้ได้ ผลตามนี้

4.      สิ้นสุดการ เขียน code  โดย กด F3=Exitจะเห็น  หน้าจอยืนยัน

 4. สิ้นสุดการเขียน Code โดยการกด F3=Exit จะเห็นหน้าจอ ยืนยัน

 

อ่านโปรแกรม RPG (ปัจจุบัน) ให้เป็น

อ่านโปรแกรม RPG (ปัจจุบัน) ให้เป็น

สำหรับ  โปรแกรมเมอร์ใหม่ (0-3 ปี)
หนึ่งในหน้าที่ คือ เรียนรู้ระบบฯงานที่มีอยู่

ผมเชื่อว่า คนสอน >50% จะบอกว่า  ให้เรียนรู้ (อ่านเอาเอง) จากโปรแกรม
บางที่จะมี  เอกสารประกอบให้ดู (ส่วนใหญ่ก็จะเก่ามาก)

ผมก็สอนงาน แบบนี้เหมือนกันครับ  : P
ก็ภาษามันมีโครงสร้าง ไม่ซับซ้อน  ดังนั้นการอ่าน/ทำความเข้าใจ  ก็ยาก
แต่ใช้ไม่ได้กับทุกกรณีครับ  บางเรื่องก็ยากเกินไปน๊ะครับ

ถ้าเป้าหมายของการสอนงาน คือ "เรียนรู้ให้เร็ว" และพร้อมทำงาน
วิธีข้างต้น  ก็ไม่ตอบโจทย์น๊ะครับ

ตย.  นาย ก ต้องมาค้นหาวิธีเขียนโปรแกรมเทคนิค abc   ใช้เวลา 1 เดือน
ด้านดี  (คิดบวกมากๆ) นาย ก เรียนรู้ด้วย "ตนเอง" ได้ (นักเรียนในฝัน)
ด้านเสีย  ใช้เวลานานไป  และไม่การันตีว่า  รู้ตรงกับที่อยากให้เรียนรู้

ความเห็นของผม : แค่ "ลงมือทำ" ในสิ่งที่คิด
(ทุกคนคิดได้  แต่ไม่ได้ลงมือทำ  อ้างว่าไม่ว่างซะงั้น)

กลับมาที่หัวข้อ  วิธีอ่านโปรแกรม (ปัจจุบัน)​ ให้เป็น

Q: เราอ่านโปรแกรม เพื่ออะไร ?

หากฏ หรือ ข้อกำหนด (condition), หาความสัมพันธ์, เรียนรู้เทคนิค
โดยปรกติ จะเริ่มดูโปรแกรม กลุ่ม Entry, Maintenance และหน้าจอผลลัพธ์ที่ใช้บ่อย

หากฏ หรือ ข้อกำหนด (condition)

- ถ้า  สินค้า  เป็นชนิดนี้   ค่า commission ให้ลดลง 5% ... ไม่พบในเอกสารพื้นฐาน

หาความสัมพันธ์

- File A01,A02 ต้องใช้คู่กับ File C05 ... ไม่มีในเอกสาร

เทคนิคต่างๆ
- แสดงผลแบบ xxx (ต้องใช้ 3 เทคนิค) ... ไม่มีในหนังสือ
- Array, SubFile ... หนังสือทั่วไปไม่พูดถึง

มา Share ประสพการณ์จากผมทีละเรื่องกันครับ

หากฏ หรือ ข้อกำหนด (condition)

ปรกติ  ผมจะเริ่มจาก สรุปหลักการขึ้น  "แบบย่อ" ขึ้นมาก่อนครับ (ประมาณครึ่งหน้า A4)
เช่น งานบัญชี Fix Asset,  งานผลิต   มี keyword อะไรบ้าง

ตย.1
       สินทรัพย์ ทุกรายการต้องมี  เลขที่ประจำตัว  บอกวันเริ่มต้น, ระยะเวลาหมดค่า, สูตรการคำนวน

เมื่ออ่านโปรแกรม อาจจะพบว่า  มีกลุ่มสินทรัพย์  บางกลุ่มต้องใช้สูตรที่แตกต่างไป (เช่น ต้องลดค่าลงแบบเรขาคณิต)  ให้บันทึกเป็น "ข้อกำหนดพิเศษ"

       สินทรัพย์ ทุกรายการต้องมี  เลขที่ประจำตัว  บอกวันเริ่มต้น, ระยะเวลาหมดค่า, สูตรการคำนวน
แบบเชิงเส้น
       ยกเว้น กลุ่มอิเลคทรอนิคส์  (รหัส E) ใช้สูตรลดค่าแบบเรขาคณิต

ตย.2
       งานผลิต  ชิ้นงาน (Item No)  ผลิตที่  (Process, machine) ณ. เวลา (วันเดือนปี,เวลา)  ได้จำนวนดี
,เสียหาย เท่าไหร่  

เมื่ออ่านโปรแกรม อาจจะพบว่า  Process A321  จะบันทึกจำนวนในรูปแบบกิโล  แทนการนับเป็นชิ้น  ให้บันทึกเป็น "ข้อกำหนดพิเศษ" 

       งานผลิต  ชิ้นงาน (Item No)  ผลิตที่  (Process, machine) ณ. เวลา (วันเดือนปี,เวลา)  ได้จำนวนดี,เสียหาย เท่าไหร่ (นับเป็นชิ้น)

       ยกเว้น  Process A321 ที่นับเป็น กิโล (ต้องเปลี่ยน กิโล เป็น ชิ้น)

หาความสัมพันธ์ (ER)

ในมหาวิทยาลัยเราเรียนการสร้าง  Table ใหม่  แต่ในงานจริง บริษัทฯ เปิดทำการมามากกว่า 20 ปี

Table ต่างๆ ถูกสร้างขึ้นมามากมายแล้ว   ดังนั้นการอ่านโปรแกรมก็คือ การหาความสัมพันธ์  ที่

อาจจะไม่เคยเห็นเอกสาร   พูดภาษาชาวบ้านคือ "เดาใจ"  ผู้สร้าง Table ในยุคนั้นออกแบบอย่างไร

โชคไม่ดี  ถ้า Developer ที่จบมาส่วนใหญ่  ออกแบบไม่เก่ง  ในยุคสมัยนั้น คงไม่ต่างกันเท่าไหร่ ...

การเดาใจจึง "ซับซ้อน"  กว่าปรกติ

อันดับแรก ต้องเชื่อว่าโปรแกรมที่กำลังอ่าน   สร้างถูกต้องตามหลักการก่อน

(ไม่จำเป็นต้องถูกต้อง 100% ก็ได้)

ตัวเอกสาร Fix Asset, งานผลิต  ถ้าจะสร้าง Table ใหม่  น่าจะต้องใช้กี่ Table

(เริ่มจาก 1 Table  -> หลาย  Table ที่สัมพันธ์กัน)  ไม่เรียกเดาใจจะเรียกอะไรครับ

เรื่องถัดมา  เข้าใจวิธี RPG เรียกใช้ DB2/400 

DB2/400 เป็น Database ที่ดีอีกตัว  ง่ายเมื่อทำงานกับ 1 Table เริ่มซับซ้อนเมื่อทำงานมากกว่า 1 Table  และ เริ่มเข้าใจยากเมื่อ บันทึก/แก้ไข ข้อมูลหลาย Table  (ยุคนี้ทำได้ง่ายขึ้น แต่ก็ยังไม่ง่ายจริงๆ)  

ดังนั้นไม่ใช่เรื่องแปลกที่ Developer ในยุคนั้นจะเลือกวิธีที่ง่าย  มากกว่าวิธีที่ถูกต้องจริงๆ (ซึ่งทำได้ยุ่งยาก)  เช่น ยุคนี้  SQL  3 Table ในครั้งเดียว  RPG ยุคใหม่จะมองผลลัพธ์เป็น 1 Table แต่ RPG ในยุคดังกล่าวจะทำทีละ Step (อ่าน Table แรก  แล้วนำแต่ละ Row ไปอ่าน Table 2 หรือ 3) 

ลองดู ตย. การเขียนในสไตล์ใหม่

SQL : -> ได้ 1 Table-Result   

     Select  *   from    Table-1 as T1   

     Left Join   Table-2  as T2 On  T1.X=T2.Y 

     Left Join   Table-3  as T3 On  T1.Y=T3.Z

RPG : (ที่ใช้คู่กับ SQL)  ทำให้ดูง่าย

     Read  Table-Result

     Do while    not EOF

           Print

           Read  Table-Result

     End Do

ตย.นี้  เรารู้แค่ Table ทั้ง 3 มี Relation  แต่ไม่รู้ว่าความสัมพันธ์เป็นแบบไหน

1:1 หรือ 1:m    ต้องทดสอบโดยต้องใช้ SQL หา Relation ทีละคู่

  Table-1  ได้ผลลัพธ์  115 rows 

เพิ่ม Join กับ Table-2  ถ้านับผลลัพธ์ได้ 115 rows เท่าเดิม -> จะได้ relation  1:1

เพิ่ม Join กับ Table-2  ถ้านับผลลัพธ์ได้มากกว่า  115 rows  -> จะได้ relation  1:m

-----------------------------------------------------------

ลองดู ตย. การเขียนที่สืบทอดกันมา

RPG :

     Pointer to  Table-1

     Read  Table-1  (one row)

     Do while    not EOF

           T1.x  Pointer to  Table-2  

           T1.y  Pointer to  Table-3

           Read  Table-3  (one row)

           Do while    not EOF

               Print

               Read  Table-3  (next row)

           End Do

           Read  Table-1  (next row)

     End Do

ตย.ข้างต้น เราจะอ่าน Relation ได้ว่า 

     Table-1 : Table-2 จะมีความสัมพันธ์ แบบ 1:1

     Table-1 : Table-3 จะมีความสัมพันธ์ แบบ 1:m

หัวข้อถัดไปยกยอดไปคราวหน้าแล้วกันครับ (เนื้อหาเริ่มยาวเกินไปแล้ว)

DB กับ RPG

DB กับ RPG

ในความเป็นจริง  บริษัทต่างๆ  ที่เปิดตัวมานานเกิน 10 ปี ต้องมีการวางโครงสร้าง DB ไว้แล้ว  

หน้าที่ของเราคือ  เข้าใจ + ใช้ "สิ่งที่มีอยู่"  ให้ดี  (มาเดาใจ  คนออกแบบเดิม กันดีกว่า)    

ความสะดวกสบายจาก สิ่งที่เรียนจบมาใหม่ๆ ทยอยเก็บใส่ลิ้นชักไปได้เลย  

กรณีที่ 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 ปีแล้ว)

ตย. 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 เล่ม (มีรายละเอียด + แตกย่อยไปมาก) 

เนื้อหา จะมีมาก (จนคนรุ่นใหม่  จะรู้สึกท้อ  เมื่อต้องมาเรียนรู้สิ่งที่มากและยาก)