ทำไมคุณถึงต้องเก็บ Enum ไว้ใน DB

ฉันเคยเห็นคำถามมากมายเช่นนี้เพื่อขอคำแนะนำเกี่ยวกับวิธีการจัดเก็บ enums ในฐานข้อมูล แต่ฉันสงสัยว่าทำไมคุณถึงทำอย่างนั้น สมมุติว่าฉันมีเอนทิตีที่Personมีgenderเขตข้อมูลและGenderenum จากนั้นตารางบุคคลของฉันมีเพศคอลัมน์

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

ลองมาอีกตัวอย่างหนึ่งที่ไม่ค่อยเต็มไปด้วยแนวคิดและความคาดหวัง ฉันได้รับ enum ที่นี่และมันเป็นชุดของลำดับความสำคัญสำหรับข้อผิดพลาด

คุณเก็บค่าอะไรในฐานข้อมูล

ดังนั้นฉันอาจจะจัดเก็บ'C', 'H', 'M'และ'L'ในฐานข้อมูล หรือ'HIGH'อื่น ๆ นี่เป็นปัญหาของข้อมูลที่พิมพ์อย่างเคร่งครัด มีชุดของค่าที่ถูกต้องที่รู้จักกันดีและหากคุณไม่ได้จัดเก็บชุดนั้นไว้ในฐานข้อมูลอาจเป็นเรื่องยากที่จะทำงานด้วย

ทำไมคุณถึงจัดเก็บข้อมูลในรหัส?

คุณมีList<String> priorities = {'CRITICAL', 'HIGH', 'MEDIUM', 'LOW'};หรือมีบางอย่างที่ส่งผลต่อโค้ด หมายความว่าคุณมีการแมปข้อมูลต่าง ๆ ในรูปแบบที่เหมาะสม (คุณใส่ตัวพิมพ์ใหญ่ทั้งหมดลงในฐานข้อมูล แต่คุณแสดงเป็นCritical) รหัสของคุณก็ยากที่จะแปล คุณผูกการแสดงฐานข้อมูลของแนวคิดกับสตริงที่เก็บไว้ในรหัส

ทุกที่ที่คุณต้องการเข้าถึงรายการนี้คุณต้องทำซ้ำรหัสหรือคลาสที่มีค่าคงที่จำนวนมาก ไม่มีตัวเลือกใดที่ดี สิ่งหนึ่งที่ไม่ควรลืมก็คือมีแอปพลิเคชั่นอื่น ๆที่อาจใช้ข้อมูลนี้ (ซึ่งอาจเขียนเป็นภาษาอื่น - เว็บแอปพลิเคชัน Java มีระบบรายงาน Crystal Reports ที่ใช้และPerlข้อมูลการป้อนงานแบทช์) เอ็นจิ้นการรายงานจำเป็นต้องทราบรายการข้อมูลที่ถูกต้อง (จะเกิดอะไรขึ้นหากไม่มีการทำเครื่องหมายใน'LOW'ลำดับความสำคัญและคุณจำเป็นต้องรู้ว่านั่นเป็นลำดับความสำคัญที่ถูกต้องสำหรับรายงานหรือไม่) และงานแบ็ตช์จะมีข้อมูล ค่าคือ

สมมุติฐานคุณอาจพูดว่า "เราเป็นร้านค้าภาษาเดียว - ทุกอย่างเขียนด้วยภาษา Java" และมี. jar เดียวที่มีข้อมูลนี้ - แต่ตอนนี้ก็หมายความว่าแอปพลิเคชันของคุณเชื่อมโยงกันอย่างแน่นหนา ข้อมูล. คุณจะต้องปล่อยส่วนการรายงานและส่วนการอัปเดตแบทช์พร้อมกับเว็บแอปพลิเคชันทุกครั้งที่มีการเปลี่ยนแปลง - และหวังว่าการเผยแพร่นั้นจะเป็นไปอย่างราบรื่นสำหรับทุกส่วน

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

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

ด้วยวิธีการ 'enum-in-the-table' คุณจะอัพเดตรายการ enum เพื่อให้มีลำดับความสำคัญใหม่ รหัสทั้งหมดที่ได้รับรายการดึงออกจากฐานข้อมูล

ข้อมูลไม่ค่อยโดดเดี่ยว

ด้วยลำดับความสำคัญคีย์ข้อมูลลงในตารางอื่น ๆที่อาจมีข้อมูลเกี่ยวกับเวิร์กโฟลว์หรือผู้ที่สามารถกำหนดลำดับความสำคัญนี้หรืออะไรก็ตาม

กลับไปที่เพศตามที่กล่าวถึงในคำถามเล็กน้อย: เพศมีลิงก์ไปยังสรรพนามที่ใช้งาน: he/his/himและshe/hers/her... และคุณต้องการหลีกเลี่ยงการเข้ารหัสที่เป็นรหัสอย่างหนัก และจากนั้นเจ้านายของคุณก็มาด้วยและคุณต้องเพิ่มว่าคุณมี'OTHER'เพศ (เพื่อให้เป็นเรื่องง่าย) และคุณต้องเชื่อมโยงเพศนี้กับthey/their/them... และเจ้านายของคุณเห็นว่า Facebook มีอะไรและ ... ดีใช่

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

แล้วดาต้าสโตร์อื่น ๆ ล่ะ?

ไม่ว่าคุณจะเก็บสิ่งนี้ไว้ที่ไหนหลักการเดียวกันก็มีอยู่

• คุณอาจมีไฟล์priorities.propนั่นคือรายการลำดับความสำคัญ คุณอ่านรายการนี้จากไฟล์คุณสมบัติ

• คุณสามารถมีฐานข้อมูลที่เก็บเอกสาร (เช่นCouchDB ) ที่มีรายการสำหรับenums(แล้วเขียนฟังก์ชันการตรวจสอบใน JavaScript ):

  {
     "_id": "c18b0756c3c08d8fceb5bcddd60006f4",
     "_rev": "1-c89f76e36b740e9b899a4bffab44e1c2",
     "priorities": [ "critical", "high", "medium", "low" ],
     "severities": [ "blocker", "bad", "annoying", "cosmetic" ]
  }
  

• คุณสามารถมีไฟล์ XML ที่มีสคีมาเล็กน้อย:

  <xs:element name="priority" type="priorityType"/>
  
  <xs:simpleType name="priorityType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="critical"/>
      <xs:enumeration value="high"/>
      <xs:enumeration value="medium"/>
      <xs:enumeration value="low"/>
    </xs:restriction>
  </xs:simpleType>
  

แนวคิดหลักเหมือนกัน ที่เก็บข้อมูลนั้นเป็นที่ที่รายการของค่าที่ถูกต้องจะต้องถูกจัดเก็บและบังคับใช้ โดยการวางไว้ที่นี่มันง่ายกว่าที่จะให้เหตุผลเกี่ยวกับรหัสและข้อมูล คุณไม่ต้องกังวลเกี่ยวกับการตรวจสอบอย่างละเอียดว่ามีอะไรบ้างในแต่ละครั้ง (มันเป็นตัวพิมพ์ใหญ่หรือต่ำกว่าทำไมมีchriticalคอลัมน์ในประเภทนี้หรือไม่ ฯลฯ ... ) เพราะคุณรู้ว่าคุณได้รับอะไรกลับมาจาก datastore สิ่งที่ว่าที่เก็บข้อมูลคาดหวังให้คุณส่งเป็นอย่างอื่น - และคุณสามารถสอบถามที่เก็บข้อมูลสำหรับรายการค่าที่ถูกต้อง

การพกพา

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

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

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

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

คุณคิดว่าข้อใดต่อไปนี้ที่จะก่อให้เกิดข้อผิดพลาดเมื่ออ่านข้อความค้นหา

select * 
from Person 
where Gender = 1

หรือ

select * 
from Person join Gender on Person.Gender = Gender.GenderId
where Gender.Label = "Female" 

ผู้คนสร้างตาราง enum ใน SQL เพราะพวกเขาพบว่าหลังสามารถอ่านได้มากขึ้นซึ่งนำไปสู่ข้อผิดพลาดในการเขียนและการบำรุงรักษา SQL ที่น้อยลง

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

ฉันไม่อยากจะเชื่อว่าคนอื่นไม่ได้พูดถึงเรื่องนี้

กุญแจต่างประเทศ

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

ฉันอยู่ในค่ายที่เห็นด้วยกับคุณ หากคุณเก็บรหัสเพศไว้ในรหัสของคุณและ tblGender ในฐานข้อมูลของคุณคุณอาจประสบปัญหาในการบำรุงรักษา คุณจะต้องจัดทำเอกสารว่าเอนทิตีทั้งสองนี้ควรมีค่าเหมือนกันดังนั้นการเปลี่ยนแปลงใด ๆ ที่คุณทำกับสิ่งที่คุณต้องทำ

จากนั้นคุณจะต้องส่งค่า enum ไปยังกระบวนงานที่เก็บไว้ดังนี้:

create stored procedure InsertPerson @name varchar, @gender int
    insert into tblPeople (name, gender)
    values (@name, @gender)

แต่คิดว่าคุณจะทำอย่างไรถ้าคุณเก็บค่าเหล่านี้ไว้ในตารางฐานข้อมูล:

create stored procedure InsertPerson @name varchar, @genderName varchar
    insert into tblPeople (name, gender)
    select @name, fkGender
    from tblGender
    where genderName = @genderName --I hope these are the same

แน่ใจว่าฐานข้อมูลเชิงสัมพันธ์นั้นถูกสร้างขึ้นโดยคำนึงถึงการเชื่อมต่อ แต่แบบสอบถามใดที่อ่านง่ายกว่า

นี่คือตัวอย่างแบบสอบถามอื่น:

create stored procedure SpGetGenderCounts
    select count(*) as count, gender
    from tblPeople
    group by gender

เปรียบเทียบกับสิ่งนี้:

create stored procedure SpGetGenderCounts
    select count(*) as count, genderName
    from tblPeople
    inner join tblGender on pkGender = fkGender
    group by genderName --assuming no two genders have the same name

นี่เป็นอีกตัวอย่างแบบสอบถาม:

create stored procedure GetAllPeople
    select name, gender
    from tblPeople

โปรดทราบว่าในตัวอย่างนี้คุณจะต้องแปลงเซลล์เพศในผลลัพธ์ของคุณจาก int เป็น enum อย่างไรก็ตามการแปลงเหล่านี้เป็นเรื่องง่าย เปรียบเทียบกับสิ่งนี้:

create stored procedure GetAllPeople
    select name, genderName
    from tblPeople
    inner join tblGender on pkGender = fkGender

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

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

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

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

หากคุณมี enum ที่กำหนดไว้ในรหัส (สำหรับรหัสทำความสะอาดและการตรวจสอบเวลาคอมไพล์) รวมถึงตารางในฐานข้อมูลฉันขอแนะนำให้เพิ่มการทดสอบหน่วยเพื่อตรวจสอบว่าทั้งสองซิงค์กันหรือไม่

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

1. อย่าทำให้ฟิลด์ ID บนตารางเป็นคอลัมน์ข้อมูลประจำตัว รวม ID และคำอธิบายเป็นฟิลด์

2. ทำสิ่งที่แตกต่างในตารางที่ช่วยให้นักพัฒนาทราบว่าค่าเป็นแบบกึ่งคงที่ / เชื่อมโยงกับการแจกแจงรหัส ในตารางการค้นหาอื่น ๆ ทั้งหมด (โดยปกติแล้วผู้ใช้สามารถเพิ่มค่าได้) ฉันมักจะมี LastChangedDateTime และ LastChangedBy แต่การไม่มีค่าเหล่านั้นในตารางที่เกี่ยวข้องกับ enum ช่วยให้ฉันจำได้ว่าพวกเขาสามารถเปลี่ยนแปลงได้โดยนักพัฒนาเท่านั้น เอกสารนี้

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

4. สร้างการผลิตส่งสคริปต์ SQL ซึ่งทำเช่นเดียวกัน แต่จากภายในฐานข้อมูล หากสร้างอย่างถูกต้องจะช่วยในการย้ายสภาพแวดล้อมเช่นกัน

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

โดยทั่วไปตารางชนิดจะไม่ซ้ำกันเป็น enum ในรหัส คุณสามารถโหลดตารางประเภทในรายการที่ถูกแคช

Class GenderList

   Public Shared Property UnfilteredList
   Public Shared Property Male = GetItem("M")
   Public Shared Property Female = GetItem("F")

End Class

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