การอ้างอิงค่าฐานข้อมูลในตรรกะทางธุรกิจ

ฉันเดาว่านี่เป็นคำถามเกี่ยวกับการเข้ารหัสและแนวทางปฏิบัติที่ดีที่สุด สมมติว่าฉันมีรายการค่าให้บอกผลไม้ที่เก็บไว้ในฐานข้อมูล (จำเป็นต้องอยู่ในฐานข้อมูลเนื่องจากตารางจะใช้เพื่อวัตถุประสงค์อื่นเช่นรายงาน SSRS) พร้อมรหัส:

1 Apple 
2 Banana 
3 Grapes

ฉันอาจนำเสนอให้กับผู้ใช้เขาเลือกหนึ่งมันจะถูกเก็บไว้ในโปรไฟล์ของเขาเป็น FavouriteFruit และ ID ที่เก็บไว้ในบันทึกของเขาในฐานข้อมูล

เมื่อพูดถึงกฎเกณฑ์ทางธุรกิจ / ลอจิกโดเมนอะไรคือคำแนะนำสำหรับการกำหนดตรรกะให้กับค่าเฉพาะ พูดถ้าผู้ใช้เลือกองุ่นฉันต้องการทำงานพิเศษบางอย่างวิธีที่ดีที่สุดในการอ้างอิงค่าองุ่นคือ:

// Hard coded name
if (user.FavouriteFruit.Name == "Grapes")

// Hard coded ID
if (user.FavoriteFruit.ID == 3) // Grapes

// Duplicate the list of fruits in an enum
if (user.FavouriteFruit.ID == (int)Fruits.Grapes)

หรืออย่างอื่น?

เนื่องจากแน่นอน FavouriteFruit จะถูกใช้ตลอดทั้งแอปพลิเคชันรายการอาจถูกเพิ่มหรือแก้ไข

บางคนอาจคิดว่าพวกเขาต้องการ 'Grapes' เปลี่ยนเป็น 'Grape' และนี่จะทำให้ตัวเลือกสตริงที่เข้ารหัสยาก

รหัส hardcoded ยังไม่ชัดเจนแม้ว่าดังที่แสดงไว้คุณสามารถเพิ่มความคิดเห็นเพื่อระบุรายการได้อย่างรวดเร็ว

ตัวเลือก enum เกี่ยวข้องกับการทำซ้ำข้อมูลจากฐานข้อมูลซึ่งดูเหมือนว่าผิดเนื่องจากอาจทำให้ข้อมูลไม่ตรงกัน

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

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

if( user.FavouriteFruit.ID == MyApplication.Grape.ID )

สิ่งที่เพิ่งเกิดขึ้นที่นี่คือฉันเห็นได้ชัดว่าโหลดทั้งแถวGrapeเข้าสู่หน่วยความจำดังนั้นฉันจึงมี ID ของมันพร้อมใช้ในการเปรียบเทียบ หากคุณบังเอิญใช้ Object-Relational Mapping (ORM) มันจะดูดีขึ้น:

if( user.FavouriteFruit == MyApplication.Grape )

(นั่นคือเหตุผลที่ฉันเรียกว่า "วัตถุที่โหลดไว้ล่วงหน้า")

ดังนั้นสิ่งที่ฉันทำคือในระหว่างการเริ่มต้นฉันโหลดตาราง "การแจงนับ" ทั้งหมดของฉัน (ตารางเล็ก ๆ เช่นวันในสัปดาห์เดือนของปีเพศและอื่น ๆ ) ลงในคลาสโดเมนแอปพลิเคชันหลัก ฉันโหลดพวกมันด้วยชื่อเพราะเห็นได้ชัดว่าMyApplication.Grapeต้องได้รับแถวที่เรียกว่า "องุ่น" และฉันยืนยันว่าพบพวกเขาทุกคน หากไม่มีเรามีข้อผิดพลาดรันไทม์ที่รับประกันในระหว่างการเริ่มต้นซึ่งเป็นข้อผิดพลาดอย่างน้อยที่สุดของข้อผิดพลาดรันไทม์ทั้งหมด

การตรวจสอบกับสตริงเป็นสิ่งที่อ่านได้มากที่สุด แต่ทำหน้าที่สองอย่าง: มันถูกใช้ทั้งเป็นตัวระบุและคำอธิบาย (ซึ่งอาจเปลี่ยนแปลงได้ด้วยเหตุผลที่ไม่เกี่ยวข้อง)

ฉันมักจะแบ่งหน้าที่ทั้งสองเป็นสาขาที่แยกกัน:

id  code    description
 1  grape   Grapes
 2  apple   Apple

คำอธิบายอาจเปลี่ยนแปลงได้ (แต่ไม่ใช่ "Grapes" เป็น "Banana") แต่ไม่อนุญาตให้เปลี่ยนรหัสได้

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

นอกจากนี้วิธีการที่มักจะมีคนจริงๆแก้ไข "องุ่น" กับ "องุ่น"? บางทีสิ่งนี้ไม่จำเป็นเลย

สิ่งที่คุณคาดหวังจากที่นี่คือตรรกะการเขียนโปรแกรมที่สามารถปรับเปลี่ยนได้โดยอัตโนมัติกับข้อมูลที่เปลี่ยนแปลง ตัวเลือกสแตติกแบบง่ายเช่น Enum ไม่ทำงานที่นี่เพราะคุณไม่สามารถเพิ่ม enums เพิ่มเติมในรันไทม์ได้

รูปแบบบางอย่างที่ฉันได้เห็น:

• Enums + ค่าเริ่มต้นเพื่อป้องกันรายการฐานข้อมูลใหม่ที่ทำลายวันโปรแกรมของคุณ
• การเข้ารหัสการกระทำที่ต้องทำ (ตรรกะบิซ) ในฐานข้อมูลนั้น ในหลายกรณีนี้เป็นไปได้มากเพราะ logics หลายคนได้รับการใช้ซ้ำ การดำเนินการตามตรรกะควรอยู่ในโปรแกรม
• คุณลักษณะ / คอลัมน์เพิ่มเติมในฐานข้อมูลเพื่อทำเครื่องหมายมูลค่าใหม่เป็น 'to-be-be' ในโปรแกรมจนกระทั่งโปรแกรมถูกปรับใช้
• ล้มเหลวอย่างรวดเร็วกลไกรอบ ๆ เส้นทางรหัสที่โหลด / โหลดใหม่ค่าจากฐานข้อมูล (หากการกระทำที่เกี่ยวข้องไม่ได้อยู่ในโปรแกรมและไม่ได้ทำเครื่องหมายว่าไม่ต้องทำโปรดอย่ารีเฟรช)

โดยทั่วไปฉันชอบข้อมูลที่สมบูรณ์ในแง่ของการอ้างถึงการกระทำที่มีความหมาย - แม้ว่าการกระทำของพวกเขาเองอาจถูกนำไปใช้ที่อื่น รหัสใด ๆ ที่กำหนดการกระทำที่เป็นอิสระจากข้อมูลนั้นมีเพียงการคัดลอกข้อมูลของคุณซึ่งส่วนใหญ่อาจจะแตกต่างและนำไปสู่ข้อบกพร่อง

การจัดเก็บไว้ในทั้งสองที่ (ในตารางและใน ENUM) นั้นไม่เลว เหตุผลมีดังต่อไปนี้:

โดยการจัดเก็บไว้ในตารางฐานข้อมูลเราสามารถบังคับใช้ Referential Integrity ในฐานข้อมูลผ่านทาง Foreign Key ดังนั้นเมื่อคุณเชื่อมโยงบุคคลหรือเอนทิตีอะไรก็ตามกับผลไม้มันเป็นเพียงผลไม้ที่มีอยู่ในตารางฐานข้อมูล

การจัดเก็บเป็น ENUM ก็สมเหตุสมผลเพราะเราสามารถเขียนโค้ดโดยไม่ต้องใช้สตริงเวทและมันทำให้โค้ดอ่านง่ายขึ้น ใช่พวกเขาต้องทำการซิงค์ แต่จริงๆแล้วมันยากแค่ไหนที่จะเพิ่มบรรทัดใน ENUM และคำสั่งแทรกใหม่ไปยังฐานข้อมูล

สิ่งหนึ่งเมื่อกำหนด ENUM แล้วอย่าเปลี่ยนค่าของมัน ตัวอย่างเช่นหากคุณมี:

• แอปเปิ้ล
• องุ่น

อย่าเปลี่ยนชื่อองุ่นเป็นองุ่น เพียงเพิ่ม ENUM ใหม่

• แอปเปิ้ล
• องุ่น
• องุ่น

หากคุณต้องการโอนย้ายข้อมูลให้ใช้การอัปเดตเพื่อย้ายองุ่นทั้งหมดไปยังองุ่น

คุณถูกต้องที่จะถามคำถามนี้มันเป็นคำถามที่ดีจริงๆเมื่อคุณพยายามป้องกันการประเมินสภาพที่ไม่ถูกต้อง

ที่กล่าวว่าการประเมินผล ( ifเงื่อนไขของคุณ) ไม่จำเป็นต้องเป็นจุดสนใจของวิธีการที่คุณได้รับมัน ให้ระวังวิธีที่คุณเผยแพร่การเปลี่ยนแปลงที่จะทำให้เกิดปัญหา 'ไม่ซิงค์'

วิธีการแบบสตริง

หากคุณต้องใช้สตริงทำไมไม่เปิดเผยฟังก์ชั่นการเปลี่ยนรายการผ่าน UI? การออกแบบระบบเพื่อให้อยู่กับการเปลี่ยนแปลงGrapeที่จะยกตัวอย่างเช่นคุณอัปเดตทั้งหมดของระเบียนปัจจุบันอ้างอิงGrapesGrape

วิธีการ ID

ฉันต้องการอ้างอิง ID เสมอแม้ว่าจะมีการอ่านง่าย The list may be added toสามารถเป็นสิ่งที่คุณจะได้รับแจ้งอีกครั้งหากคุณเปิดเผยคุณสมบัติ UI ดังกล่าว หากคุณกังวลเกี่ยวกับการจัดเรียงรายการที่เปลี่ยน id ให้เผยแพร่การเปลี่ยนแปลงดังกล่าวไปยังระเบียนที่ต้องพึ่งพาทั้งหมดอีกครั้ง ในทำนองเดียวกันกับข้างต้น ตัวเลือกอื่น (ทำตามแบบแผนการฟื้นฟูที่เหมาะสมจะต้องมีคอลัมน์ enum / id ของคุณ - และอ้างอิงFruitDetailตารางรายละเอียดเพิ่มเติมซึ่งมีคอลัมน์ 'คำสั่งซื้อ' ที่คุณสามารถค้นหาได้)

ไม่ว่าจะด้วยวิธีใดคุณจะเห็นว่าฉันแนะนำให้ควบคุมการแก้ไขหรืออัปเดตรายการของคุณ ไม่ว่าคุณจะทำสิ่งนี้ผ่านการใช้ ORM หรือการเข้าถึงข้อมูลอื่น ๆ จะถูกกำหนดโดยเฉพาะเทคโนโลยีของคุณ สิ่งที่คุณต้องทำคือต้องการให้คนที่อยู่ห่างจากฐานข้อมูลสำหรับการเปลี่ยนแปลงเช่นนั้น - ซึ่งฉันคิดว่าใช้ได้ CRM หลักส่วนใหญ่จะทำให้ความต้องการเดียวกัน

ปัญหาที่พบบ่อยมาก ในขณะที่การทำซ้ำด้านไคลเอนต์ข้อมูลอาจดูเหมือนละเมิดหลักการDRYแต่เป็นเพราะความแตกต่างในกระบวนทัศน์ระหว่างเลเยอร์

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

บางครั้งมันก็เกิดขึ้นด้วยวิธีอื่นเช่นกัน ค่า enum ใหม่ถูกเพิ่มเข้ากับฝั่งไคลเอ็นต์ แต่การอัพเดต DB ไม่สามารถเกิดขึ้นได้จนกว่าจะถึงเวลาที่ DBA สามารถใช้การเปลี่ยนแปลงได้

สมมติว่าเรากำลังพูดถึงสิ่งที่เป็นหลักการค้นหาแบบคงที่แล้วตัวเลือกที่สาม - enum - นั้นเป็นทางเลือกที่มีเหตุผลเท่านั้น มันคือสิ่งที่คุณจะทำถ้าฐานข้อมูลไม่เกี่ยวข้องดังนั้นจึงสมเหตุสมผล

คำถามจะกลายเป็นคำถามเกี่ยวกับวิธีเก็บ enums และตารางแบบคงที่ / ค้นหาในฐานข้อมูลให้ตรงกันและน่าเสียดายที่ไม่ใช่ปัญหาที่ฉันยังมีคำตอบที่สมบูรณ์

โดยการเลือกฉันทำการบำรุงรักษา schema ของฉันทั้งหมดในรหัสและดังนั้นฉันสามารถเก็บความสัมพันธ์ระหว่างบิลด์ของแอปพลิเคชันและเวอร์ชันสกีมาที่คาดไว้ดังนั้นจึงเป็นเรื่องตรงไปตรงมาเพื่อให้การค้นหาและ enum ซิงค์ แต่สิ่งที่ต้องจำ ทำ. มันจะดีกว่าถ้ามันเป็นแบบอัตโนมัติ (และการทดสอบการรวมอัตโนมัติเพื่อให้แน่ใจว่าการจับคู่ enums และการค้นหาจะช่วยได้) แต่นั่นไม่ใช่สิ่งที่ฉันเคยนำมาใช้