เมื่อใดที่หนึ่งค่าข้อมูลจริงของฮาร์ดโค้ดในรหัสเมื่อเทียบกับการใช้ฐานข้อมูล

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

ฉันทามติที่ยังไม่ได้บอกกล่าวมักจะเป็นเช่นนั้น (*):

หากเป็นตัวแปรเดียวหรือโครงสร้างอย่างง่ายหรืออาเรย์ของค่าสองสามค่าให้ใส่ข้อมูลลงในโค้ด

[* ฉันทามติได้ถกเถียงกันในความคิดเห็นและคำตอบ แต่โดยทั่วไปฉันต้องการหลักฐานบางอย่างเพื่อเริ่มคำถามดังนั้นอย่าลังเลที่จะท้าทายและพัฒนามัน ]

ตัวอย่าง:

$number = 44;
$colors = array("blue", "yellow", ... "mauve");

หากมีข้อมูลมากกว่าร้อยแถวในประเภทเดียวกันให้ใช้ฐานข้อมูล

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

ตัวอย่าง:
สมมติว่า บริษัท ของคุณใช้เฟรมมอเตอร์ที่แตกต่างกัน 10-15 ประเภทซึ่งสามารถแสดงเป็น "412T" คุณมีพวกมันประมาณ 30 ตัวและพวกมันเปลี่ยนไม่ค่อย คุณสามารถสร้างตารางฐานข้อมูลสำหรับรหัสเหล่านั้นหรือฮาร์ดโค้ดในฐานข้อมูล ในกรณีนี้มอเตอร์คงที่สิ่งทางกายภาพที่ไม่น่าจะเปลี่ยนบ่อย

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

อีกตัวอย่าง (จริง) ที่ฉันสามารถใช้ได้คือคำถามของฉัน: /programming/26169751/how-to-best-get-the-data-out-of-a-lookup-table (ปัจจุบัน 48 แถวของข้อมูลตัวเลือก)

ฉันไม่คิดว่าข้อความทั้งสองนี้แสดงถึงฉันทามติเกี่ยวกับข้อมูลโค้ดเมื่อใด:

หากเป็นตัวแปรเดียวหรือโครงสร้างอย่างง่ายหรืออาเรย์ของค่าสองสามค่าให้ใส่ข้อมูลลงในโค้ด

หากมีข้อมูลมากกว่าร้อยแถวในประเภทเดียวกันให้ใช้ฐานข้อมูล

ตัวอย่างเคาน์เตอร์ธรรมดา (ฉันแน่ใจว่ามีดีกว่า): ตารางไวยากรณ์ภาษาการเขียนโปรแกรมเป็นโครงสร้างขนาดใหญ่ที่ซับซ้อนที่มักจะเขียนโค้ดยาก ลองดูตัวอย่างจากที่รหัสที่มา Perl

แต่ฉันจะมุ่งเน้นไปที่การถามก่อน:

• ข้อมูลมีการเปลี่ยนแปลงบ่อยแค่ไหน?

• ใครบ้างที่อาจต้องเปลี่ยน

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

หากคำตอบของ "ใครเป็นคนเปลี่ยน" คือ "ใครก็ตามที่นอกเหนือจากโปรแกรมเมอร์" คุณไม่ควรเขียนโค้ดอย่างหนักหน่วง

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

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

ฉันจะไปกับตัวเลือกที่สาม: ไฟล์กำหนดค่า!

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

motorFramesString=412T, 413T, ...

ในฤดูใบไม้ผลิ config:

<bean="motorFrameManager" class="myCompany.MotorFrameManager" >
    <property name="motorFrames" value="${motorFrames}"/>
</bean>

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

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

ตัวอย่างที่ซับซ้อนมากขึ้นเช่นสิ่งที่คุณเชื่อมโยงสามารถทำได้เช่นกันโดยมีหรือไม่มีคุณสมบัติ

ในผลิตภัณฑ์คุณสมบัติ:

productA.name=Product A 123
productA.hasMotor=true
productA.numFeet=1
productA.hasOutlet=true
productA.needsManual=true

productB.name=Product B 456
productB.hasMotor=false
productB.numFeet=1
productB.hasOutlet=true
productB.needsManual=true

ในไฟล์กำหนดค่าสปริงของคุณ:

<bean name="productA" class="com.mycompany.Product">
   <property name="name" value="${productA.name}"/>
   <property name="hasMotor" value="${productA.hasMotor}"/>
   <!-- rest omitted for brevity -->
</bean>
<bean name="productB" class="com.mycompany.Product">
   <property name="name" value="${productB.name}"/>
   <property name="hasMotor" value="${productB.hasMotor}"/>
   <!-- rest omitted for brevity -->
</bean>
<!-- configure as many beans as needed -->
<bean="motorFrameManager" class="myCompany.MotorFrameManager" >
    <property name="motorFrames"> <!-- assumes that MotorFrameManager has a property motorFrames which is a List<Product> -->
        <list>
            <ref bean="productA"/>
            <ref bean="productB"/>
        </list>
    </property>
</bean>

สิ่งที่ดีเกี่ยวกับเรื่องนี้คือถ้าข้อมูลต้นฉบับของคุณเป็นสเปรดชีต (เช่นในคำถามที่คุณเชื่อมโยง) คุณสามารถใช้แมโครใน Excel เพื่อสร้างคุณสมบัติและตัวอย่างข้อมูลในฤดูใบไม้ผลิโดยอัตโนมัติ

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

ความถี่

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

ใคร

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

หัวข้อทั่วไป

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

การทดสอบ

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

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

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

แน่นอนว่าไฟล์กำหนดค่ารูปภาพเสียง ฯลฯ จะถูกเก็บไว้ในระบบไฟล์ได้ดีกว่า

หากมีโอกาสแม้แต่น้อยที่สุดที่คุณจะได้รับโทรศัพท์ทำให้คุณต้องสร้างแอปพลิเคชันใหม่เนื่องจากมีการเปลี่ยนแปลงรหัสฮาร์ดโค้ดบางอย่างโปรดอย่าเขียนโค้ดให้ยุ่งยาก อย่างน้อยที่สุดก็เก็บไว้ในไฟล์ config หรือตาราง db คุณไม่จำเป็นต้องจัดเตรียม UI ใด ๆ เพื่อรักษาความจำเป็น แต่การโทรเข้าและเปลี่ยนไฟล์กำหนดค่าหรือเรียกใช้ SQL UPDATE บนโต๊ะย่อมดีกว่าที่จะสร้างการแข่งขันยิงขึ้นมาใหม่ทั้งหมด

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

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

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

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

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

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

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

แน่นอนคุณสามารถจัดเก็บข้อมูลฐานข้อมูลในไฟล์กำหนดค่านั้นในรูปแบบที่เข้ารหัส แต่แล้วคุณต้องมีคีย์ถอดรหัสที่จัดเก็บไว้ที่ใดที่หนึ่ง

นอกจากนั้นยังมีสิ่งที่ไม่เคยเปลี่ยนแปลง สิ่งต่าง ๆ เช่นค่าคงที่ตามธรรมชาติ (G, pi, e, คุณตั้งชื่อ), สิ่งต่าง ๆ อาจจะเหมือนกับนิพจน์ปกติบางอย่างเช่นการตรวจสอบอีเมล