วิธีปฏิบัติที่ดีที่สุด: รูปแบบการเขียนโปรแกรมแอปฐานข้อมูล


11

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

คิดว่าคำถามของฉันสามารถอธิบายได้ดีที่สุดจากตัวอย่าง มี 2 ​​วิธีที่ฉันใช้ตอนนี้บอกว่าฉันมีวัตถุ / คลาสอินวอยซ์:

แรกคือการใช้ฟังก์ชั่นสมาชิกคงที่

class Invoice
{
   int id;
   string ref;
   int customer_id;
   date created;
   date due;

   static id create();
   static bool update(id, field1, field2, ...);
   static bool delete(id);
   static bool get(id);
};

วิธีที่สองคือการใส่ทุกสิ่งลงในวัตถุฐานข้อมูล:

class Database extends ProprietaryDBConnecter, Singleton
{
   id createInvoice();
   bool updateInvoice(id, field1, field2, ...);
   bool deleteInvoice(id);
   bool getInvoice(id);

   id createCustomer();
   bool updateCustomer(id, field1, field2, ...);
   bool deleteCustomer(id);
   bool getCustomer(id);

   // etc...
}

ฉันพบว่าทั้งสองวิธีฟังก์ชันสมาชิก (SQL) ไม่สามารถแยกออกได้มากจาก "มุมมอง" ในที่ "มุมมอง" กำหนดสิ่งที่ชั้นเรียนต้องมีและดูเหมือนว่าจะทำลายสถาปัตยกรรมเอกสาร / มุมมอง

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

ไม่ทราบว่าฉันอธิบายคำถามอย่างชัดเจนอะไรคือวิธีที่ดีที่สุดในการออกแบบสถาปัตยกรรม / รูปแบบการออกแบบ / อะไรที่มันรู้จักกันในชื่อนี้?

ขอบคุณสำหรับคำแนะนำ

คำตอบ:


14

ฉันคิดว่าคุณสามารถใช้ ORM ได้

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

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


5
+1 สำหรับทุกอย่างไม่ต้อง OOP (แม้ว่า ORMs บางคนมีความสุขมาก!)
ฮาเวียร์

1
O / RM นั้นดี แต่การใช้มันไม่ได้หมายความว่าคุณไม่สามารถออกแบบฐานข้อมูลได้ดี
BlackICE

1
@ David ฉันยอมรับว่าเป็นจริงในมือของคนที่รู้ว่าเขากำลังทำอะไรอยู่ และฉันแนะนำให้เขาดู ORM แต่จริงๆแล้วถ้าคุณไม่รู้การออกแบบฐานข้อมูลก่อน ORM เป็นเครื่องมือที่อันตราย
HLGEM

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

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

10

ฉันไม่สามารถหาโครงสร้างที่เติมเต็มวิธีการของ OOP ที่ห่อหุ้มการใช้งานฐานข้อมูล

ดูเหมือนว่าคุณกำลังอธิบายวัตถุสัมพันธ์ต้านทานไม่ตรงกัน

มีหลายสิ่งที่ควรจะแก้ไข OODBMS นี้เครื่องมือ ORM ซึ่งเป็นโฮสต์ของเครื่องมือเข้าถึงข้อมูล

ฉันคิดว่าความจริงที่ว่ามีทางออกมากมายทำให้ฉันเชื่อว่า One One Solution ™ไม่มีอยู่จริง

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


ดูเหมือนว่าจะเป็นในทางที่เข้มงวดมากขึ้น
Jake

2

หากคุณไม่ต้องการที่จะใช้กระดาษห่อออมใช้ฐานข้อมูลที่จัดเก็บข้อมูลรูปแบบการสนับสนุน OOP เหมือนMongoDB

MongoDB (จาก "Hu Mongoเรา") เป็นข้ามแพลตฟอร์มฐานข้อมูลเอกสารเชิงระบบ จัดเป็นฐานข้อมูล " NoSQL ", MongoDB eschews โครงสร้างฐานข้อมูลเชิงสัมพันธ์แบบตารางตามความต้องการของเอกสารเหมือนJSONกับ schema แบบไดนามิก (MongoDB เรียกรูปแบบBSON ) ทำให้การรวมข้อมูลในแอปพลิเคชันบางประเภทง่ายขึ้นและเร็วขึ้น ..

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.