ข้อผิดพลาดในการพัฒนาฐานข้อมูลที่ทำโดยนักพัฒนาแอปพลิเคชัน [ปิด]

อะไรคือข้อผิดพลาดในการพัฒนาฐานข้อมูลทั่วไปที่ผู้พัฒนาโปรแกรมทำ?

1. ไม่ใช้ดัชนีที่เหมาะสม

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

2. ไม่บังคับใช้ Referential Integrity

ฐานข้อมูลของคุณอาจแตกต่างกันไปที่นี่ แต่ถ้าฐานข้อมูลของคุณรองรับ Referential Integrity ซึ่งหมายความว่ากุญแจต่างประเทศทั้งหมดรับประกันว่าจะชี้ไปยังเอนทิตีที่มีอยู่ - คุณควรใช้งาน

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

เพิ่มเติมที่นี่:

• ความสำคัญของข้อ จำกัด เช่น NOT NULL และ KEY ต่างประเทศคืออะไรถ้าฉันจะควบคุมอินพุตฐานข้อมูลด้วย php อยู่เสมอ
• คีย์ต่างประเทศจำเป็นจริงๆในการออกแบบฐานข้อมูลหรือไม่?
• คีย์ต่างประเทศจำเป็นจริงๆในการออกแบบฐานข้อมูลหรือไม่?

3. การใช้คีย์หลักแบบธรรมชาติแทนคีย์หลัก (เทคนิค)

คีย์ธรรมชาติคือกุญแจที่อยู่บนพื้นฐานของข้อมูลที่มีความหมายภายนอกซึ่งเป็นเอกลักษณ์ ตัวอย่างทั่วไปคือรหัสผลิตภัณฑ์รหัสสถานะสองตัวอักษร (สหรัฐอเมริกา) หมายเลขประกันสังคมและอื่น ๆ คีย์หลักตัวแทนหรือทางเทคนิคคือกุญแจที่ไม่มีความหมายภายนอกระบบ พวกเขาถูกคิดค้นขึ้นมาเพื่อระบุเอนทิตี้และโดยทั่วไปจะเพิ่มฟิลด์อัตโนมัติ (SQL Server, MySQL, อื่น ๆ ) หรือลำดับ (ออราเคิลสะดุดตาที่สุด)

ในความคิดของคุณควรเสมอใช้แป้นตัวแทน ปัญหานี้เกิดขึ้นในคำถามเหล่านี้:

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

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

โปรดจำไว้ว่าแม้แต่ประเทศต่างๆก็สามารถหยุดอยู่ได้ (ตัวอย่างเช่นยูโกสลาเวีย)

4. การเขียนแบบสอบถามที่ต้องใช้DISTINCTในการทำงาน

คุณมักเห็นสิ่งนี้ในคิวรีที่สร้างโดย ORM ดูผลการบันทึกจาก Hibernate และคุณจะเห็นข้อความค้นหาทั้งหมดเริ่มต้นด้วย:

SELECT DISTINCT ...

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

จากเหตุผลที่ฉันไม่ชอบ :

ที่สิ่งต่าง ๆ เริ่มมีรสเปรี้ยวในความคิดของฉันคือเมื่อนักพัฒนากำลังสร้างแบบสอบถามจำนวนมากเข้าร่วมตารางด้วยกันและในทันใดเขาก็ตระหนักว่าดูเหมือนว่าเขากำลังได้รับแถวที่ซ้ำกัน (หรือมากกว่า) และการตอบสนองทันทีของเขา ... "การแก้ปัญหา" ของเขากับ "ปัญหา" นี้คือการใช้คำหลัก DISTINCT และPOOF ปัญหาทั้งหมดของเขาก็หายไป

5. การรวมกลุ่มที่โปรดปรานมากกว่าการรวม

ข้อผิดพลาดทั่วไปอีกประการหนึ่งโดยผู้พัฒนาแอปพลิเคชันฐานข้อมูลคือการไม่ทราบว่าการรวมตัวที่มีราคาแพงมากขึ้น (เช่นGROUP BYข้อ) สามารถเปรียบเทียบกับการรวมได้อย่างไร

เพื่อให้คุณเข้าใจว่าเรื่องนี้แพร่สะพัดไปได้อย่างไรฉันได้เขียนหัวข้อนี้หลาย ๆ ครั้งที่นี่และลงคะแนนมาก ตัวอย่างเช่น:

จากคำสั่ง SQL -“ เข้าร่วม” กับ“ จัดกลุ่มตามและมี” :

แบบสอบถามครั้งแรก:

SELECT userid
FROM userrole
WHERE roleid IN (1, 2, 3)
GROUP by userid
HAVING COUNT(1) = 3

เวลาสอบถาม: 0.312 วิ

แบบสอบถามที่สอง:

SELECT t1.userid
FROM userrole t1
JOIN userrole t2 ON t1.userid = t2.userid AND t2.roleid = 2
JOIN userrole t3 ON t2.userid = t3.userid AND t3.roleid = 3
AND t1.roleid = 1

เวลาสอบถาม: 0.016 วิ

ถูกตัอง. รุ่นเข้าร่วมที่ฉันเสนอนั้นเร็วกว่ารุ่นรวมยี่สิบเท่า

6. ไม่ลดความซับซ้อนของการค้นหาที่ซับซ้อนผ่านมุมมอง

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

• ปาร์ตี้ : ผู้คนและองค์กร;
• บทบาทของพรรค : สิ่งที่บุคคลเหล่านั้นทำเช่นลูกจ้างและนายจ้าง
• ปาร์ตี้บทบาทความสัมพันธ์ : บทบาทเหล่านั้นเกี่ยวข้องกันอย่างไร

ตัวอย่าง:

• เท็ดเป็นคนประเภทย่อยของพรรค;
• เท็ดมีบทบาทมากมายหนึ่งในนั้นคือพนักงาน
• Intel เป็นองค์กรซึ่งเป็นประเภทย่อยของภาคี
• Intel มีบทบาทมากมายหนึ่งในนั้นคือนายจ้าง
• Intel ใช้ Ted ซึ่งหมายถึงความสัมพันธ์ระหว่างบทบาทที่เกี่ยวข้อง

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

CREATE VIEW vw_employee AS
SELECT p.title, p.given_names, p.surname, p.date_of_birth, p2.party_name employer_name
FROM person p
JOIN party py ON py.id = p.id
JOIN party_role child ON p.id = child.party_id
JOIN party_role_relationship prr ON child.id = prr.child_id AND prr.type = 'EMPLOYMENT'
JOIN party_role parent ON parent.id = prr.parent_id = parent.id
JOIN party p2 ON parent.party_id = p2.id

ทันใดนั้นคุณก็มีมุมมองที่ง่ายมากของข้อมูลที่คุณต้องการ แต่ในรูปแบบข้อมูลที่มีความยืดหยุ่นสูง

7. ไม่ฆ่าเชื้ออินพุต

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

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

8. ไม่ใช้ข้อความที่เตรียมไว้

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

SELECT * FROM users WHERE username = 'bob'

VS

SELECT * FROM users WHERE username = ?

หรือ

SELECT * FROM users WHERE username = :username

ขึ้นอยู่กับแพลตฟอร์มของคุณ

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

การใช้คำสั่งที่เตรียมไว้จะทำให้คุณมีสถิติที่มีความหมายเกี่ยวกับความถี่ในการใช้คำค้นหาบางคำ

คำสั่งที่เตรียมไว้จะช่วยปกป้องคุณจากการถูกโจมตีจากการฉีด SQL

9. การทำให้ปกติไม่เพียงพอ

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

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

สิ่งนี้เกิดขึ้นในวิธีที่ดีที่สุดสำหรับการจัดเก็บรายการ ID ผู้ใช้ :

ฉันเคยเห็นในระบบอื่น ๆ ที่รายการถูกเก็บไว้ในอาร์เรย์ PHP ต่อเนื่อง

แต่การขาดการปรับสภาพปกติมีหลายรูปแบบ

มากกว่า:

• การทำให้เป็นมาตรฐาน: ไกลแค่ไหนเพียงพอหรือไม่
• SQL โดยการออกแบบ: ทำไมคุณต้องการฐานข้อมูลให้เป็นมาตรฐาน

10. การทำให้ปกติมากเกินไป

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

ฉันเคยทำงานในระบบที่มีลำดับชั้นมากสำหรับลูกค้าที่ไปเช่น:

Licensee ->  Dealer Group -> Company -> Practice -> ...

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

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

มากกว่า:

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

11. การใช้ส่วนโค้งพิเศษ

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

จากแนวทางปฏิบัติไปจนถึงการออกแบบฐานข้อมูลเชิงสัมพันธ์ :

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

12. ไม่ทำการวิเคราะห์ประสิทธิภาพเกี่ยวกับข้อความค้นหาเลย

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

13. การพึ่งพายูเนี่ยนทั้งหมดและโดยเฉพาะอย่างยิ่งโครงสร้างยูเนี่ยน

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

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

ยูเนี่ยนโดยเฉพาะอย่างยิ่งเมื่อใช้ในการเข้าร่วมหรือแบบสอบถามย่อยขึ้นอยู่กับสามารถทำลายฐานข้อมูล พยายามหลีกเลี่ยงพวกเขาทุกครั้งที่ทำได้

14. การใช้หรือเงื่อนไขในแบบสอบถาม

สิ่งนี้อาจดูไม่เป็นอันตราย หลังจากทั้งหมด ANDs ก็โอเค หรือควรตกลงด้วยใช่ไหม ไม่ถูกต้อง. โดยทั่วไปเงื่อนไข AND จะจำกัดชุดข้อมูลในขณะที่เงื่อนไข OR เพิ่มขึ้นนั้นจะแต่ไม่ใช่ในลักษณะที่ให้ยืมเพื่อการปรับให้เหมาะสม โดยเฉพาะอย่างยิ่งเมื่อเงื่อนไขที่แตกต่างกันหรืออาจตัดกันจึงบังคับให้เครื่องมือเพิ่มประสิทธิภาพการดำเนินการ DISTINCT อย่างมีประสิทธิภาพบนผลลัพธ์

แย่:

... WHERE a = 2 OR a = 5 OR a = 11

ที่ดีกว่า:

... WHERE a IN (2, 5, 11)

ตอนนี้เครื่องมือเพิ่มประสิทธิภาพ SQL ของคุณอาจเปลี่ยนคิวรีแรกให้เป็นคิวรีได้อย่างมีประสิทธิภาพ แต่มันอาจจะไม่ อย่าทำอย่างนั้น

15. ไม่ได้ออกแบบตัวแบบข้อมูลของพวกเขาเพื่อปล่อยกู้ให้กับโซลูชันที่มีประสิทธิภาพสูง

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

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

การเพิ่มประสิทธิภาพก่อนวัยอันควรเป็นรากฐานของความชั่วร้ายทั้งหมด

16. การใช้ธุรกรรมฐานข้อมูลไม่ถูกต้อง

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

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

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

• เริ่มต้นธุรกรรมก่อนคำสั่งแรก
• ทำธุรกรรมหลังจากคำสั่งสุดท้าย
• ในข้อผิดพลาดใด ๆ ย้อนกลับการทำธุรกรรม และ NB มาก! อย่าลืมข้าม / ยกเลิกงบทั้งหมดที่ตามหลังข้อผิดพลาด

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

17. ไม่เข้าใจกระบวนทัศน์ 'set-based'

ภาษา SQL เป็นไปตามกระบวนทัศน์เฉพาะที่เหมาะกับปัญหาเฉพาะประเภท ส่วนขยายเฉพาะผู้ขายที่หลากหลายแม้ว่าภาษาจะพยายามจัดการกับปัญหาที่ไม่สำคัญในภาษาต่างๆเช่น Java, C #, Delphi เป็นต้น

การขาดความเข้าใจนี้แสดงออกมาในไม่กี่วิธี

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

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

การออกแบบฐานข้อมูลที่สำคัญและข้อผิดพลาดในการเขียนโปรแกรมที่ทำโดยนักพัฒนา

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

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

• กลัวการเขียน SQL SQL ไม่ใช่วิทยาศาสตร์จรวดและจริงๆแล้วค่อนข้างดีในการทำงาน เลเยอร์การแมป O / R ค่อนข้างดีในการทำแบบสอบถาม 95% ที่ง่ายและพอดีกับโมเดล บางครั้ง SQL เป็นวิธีที่ดีที่สุดในการทำงาน

• นโยบาย 'ไม่มีขั้นตอนการจัดเก็บ' แบบดันทุรัง ไม่ว่าคุณจะเชื่อว่าขั้นตอนการจัดเก็บนั้นผิดหรือเปล่าก็ตามทัศนคติแบบดื้อรั้นแบบนี้ไม่มีที่สำหรับโครงการซอฟต์แวร์

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

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

การใช้งานมากเกินไปและ / หรือการพึ่งพากระบวนการจัดเก็บ

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

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

ฉันเพิ่งต้องช่วยรักษาและปรับปรุงเดสก์ท็อปเดลฟายขนาดใหญ่ซึ่ง 70% ของตรรกะทางธุรกิจและกฎถูกนำไปใช้ในขั้นตอนการจัดเก็บ 1400 SQL Server (ส่วนที่เหลือในตัวจัดการเหตุการณ์ UI) นี่เป็นฝันร้ายส่วนใหญ่เกิดจากการแนะนำการทดสอบหน่วยที่มีประสิทธิภาพให้กับ TSQL การขาดการห่อหุ้มและเครื่องมือที่ไม่ดี (Debuggers, บรรณาธิการ)

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

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

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

ไม่ได้ใช้ดัชนี

ประสิทธิภาพไม่ดีเกิดจากเคียวรี่ย่อยที่สัมพันธ์กัน

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

ยกโทษให้ตัวอย่างที่ประดิษฐ์และไวยากรณ์ของ Oracle แต่สมมติว่าคุณต้องการค้นหาพนักงานทุกคนที่ได้รับการว่าจ้างในร้านค้าของคุณตั้งแต่ครั้งสุดท้ายที่ร้านค้ามียอดขายน้อยกว่า 10,000 ดอลลาร์ต่อวัน

select e.first_name, e.last_name
from employee e
where e.start_date > 
        (select max(ds.transaction_date)
         from daily_sales ds
         where ds.store_id = e.store_id and
               ds.total < 10000)

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

select e.first_name, e.last_name
from employee e,
     (select ds.store_id,
             max(s.transaction_date) transaction_date
      from daily_sales ds
      where ds.total < 10000
      group by s.store_id) dsx
where e.store_id = dsx.store_id and
      e.start_date > dsx.transaction_date

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

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

จากประสบการณ์ของฉัน:
ไม่สื่อสารกับ DBA ที่มีประสบการณ์

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

ลืมที่จะตั้งค่าความสัมพันธ์ระหว่างตาราง ฉันจำได้ว่าต้องทำความสะอาดเมื่อฉันเริ่มทำงานกับนายจ้างปัจจุบันของฉัน

การใช้ Excel สำหรับการจัดเก็บข้อมูล (จำนวนมาก)

ฉันเคยเห็น บริษัท ที่มีหลายพันแถวและใช้หลายแผ่นงาน (เนื่องจากขีด จำกัด แถวที่ 65535 ใน Excel รุ่นก่อนหน้า)

Excel เหมาะสำหรับรายงานงานนำเสนอข้อมูลและงานอื่น ๆ แต่ไม่ควรถือว่าเป็นฐานข้อมูล

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

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

ไม่ได้ใช้การสืบค้นแบบมีพารามิเตอร์ พวกเขากำลังมีประโยชน์สวยในการหยุดSQL Injection

นี่เป็นตัวอย่างเฉพาะของการไม่ฆ่าเชื้อข้อมูลอินพุตที่กล่าวถึงในคำตอบอื่น

ฉันเกลียดเมื่อนักพัฒนาใช้คำสั่ง select ที่ซ้อนกันหรือแม้กระทั่งฟังก์ชั่นการคืนค่าผลลัพธ์ของคำสั่ง select ภายในส่วน "SELECT" ของแบบสอบถาม

ฉันแปลกใจจริง ๆ ที่ฉันไม่เห็นที่นี่ที่อื่นบางทีฉันอาจมองข้ามถึงแม้ว่า @adam มีปัญหาที่คล้ายกันที่ระบุไว้

ตัวอย่าง:

SELECT
    (SELECT TOP 1 SomeValue FROM SomeTable WHERE SomeDate = c.Date ORDER BY SomeValue desc) As FirstVal
    ,(SELECT OtherValue FROM SomeOtherTable WHERE SomeOtherCriteria = c.Criteria) As SecondVal
FROM
    MyTable c

ในสถานการณ์สมมตินี้ถ้า MyTable ส่งคืน 10,000 แถวผลลัพธ์จะเหมือนกับว่าแบบสอบถามเพิ่งเรียกใช้แบบสอบถาม 20001 เนื่องจากจะต้องเรียกใช้แบบสอบถามเริ่มต้นบวกแบบสอบถามแต่ละตารางอื่น ๆ หนึ่งครั้งสำหรับแต่ละบรรทัดของผลลัพธ์

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

ตัวอย่างที่ดีกว่า (ไม่จำเป็นต้องสมบูรณ์) จะเป็นดังนี้:

SELECT
     s.SomeValue As FirstVal
    ,o.OtherValue As SecondVal
FROM
    MyTable c
    LEFT JOIN (
        SELECT SomeDate, MAX(SomeValue) as SomeValue
        FROM SomeTable 
        GROUP BY SomeDate
     ) s ON c.Date = s.SomeDate
    LEFT JOIN SomeOtherTable o ON c.Criteria = o.SomeOtherCriteria

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

สำหรับฐานข้อมูลที่ใช้ SQL:

1. ไม่ใช้ประโยชน์จาก CLUSTERED INDEXES หรือเลือกคอลัมน์ที่ไม่ถูกต้องไปที่ CLUSTER
2. ไม่ใช้ประเภทข้อมูล SERIAL (autonumber) เป็นคีย์หลักเพื่อเข้าร่วมกับ FOREIGN KEY (INT) ในความสัมพันธ์ตารางหลัก / รอง
3. ไม่อัปเดตสถิติในตารางเมื่อมีการแทรกหรือลบเรกคอร์ดจำนวนมาก
4. ไม่จัดระเบียบใหม่ (เช่นการยกเลิกการโหลดการลดการสร้างใหม่การโหลดและการทำดัชนีใหม่) ตารางเมื่อมีการแทรกหรือลบแถวจำนวนมาก (เครื่องมือบางตัวจะเก็บแถวที่ถูกลบในตารางด้วยแฟลกการลบ)
5. ไม่ได้ใช้ประโยชน์จากการยั่วยุให้เกิดการแสดงออก (ถ้าสนับสนุน) ในตารางขนาดใหญ่ที่มีอัตราการทำธุรกรรมสูง
6. การเลือกประเภทข้อมูลที่ไม่ถูกต้องสำหรับคอลัมน์!
7. ไม่เลือกชื่อคอลัมน์ที่เหมาะสม
8. ไม่เพิ่มคอลัมน์ใหม่ที่ท้ายตาราง
9. ไม่สร้างดัชนีที่เหมาะสมเพื่อรองรับการสืบค้นที่ใช้บ่อย
10. การสร้างดัชนีในคอลัมน์ที่มีค่าน้อยที่สุดและสร้างดัชนีที่ไม่จำเป็น
    ... ที่จะเพิ่ม

• ไม่ทำการสำรองข้อมูลก่อนแก้ไขปัญหาภายในฐานข้อมูลการผลิต

• การใช้คำสั่ง DDL กับวัตถุที่เก็บไว้ (เช่นตารางมุมมอง) ในขั้นตอนการจัดเก็บ

• กลัวการใช้ proc ที่เก็บไว้หรือกลัวการใช้คำสั่ง ORM เมื่อใดก็ตามที่มีประสิทธิภาพมากขึ้น / เหมาะสมที่จะใช้

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

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

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

• การยกเลิก ORM เช่น Hibernate ออกจากมือด้วยเหตุผลอย่าง "มันวิเศษเกินไป" หรือ "ไม่ได้อยู่ในมือของฉันฐานข้อมูล "
• พึ่งพา ORM มากเกินไปเช่น Hibernate และพยายามใส่ในที่ที่ไม่เหมาะสม

1 -ไม่จำเป็นต้องใช้ฟังก์ชันบนค่าในส่วนคำสั่งที่มีผลลัพธ์ของดัชนีนั้นไม่ได้ถูกใช้

ตัวอย่าง:

where to_char(someDate,'YYYYMMDD') between :fromDate and :toDate

แทน

where someDate >= to_date(:fromDate,'YYYYMMDD') and someDate < to_date(:toDate,'YYYYMMDD')+1

และในระดับน้อย: ไม่เพิ่มดัชนีการทำงานให้กับค่าที่ต้องการ ...

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

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

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

4 -ไม่มากเกี่ยวกับฐานข้อมูลต่อ se แต่น่ารำคาญแน่นอน ไม่สนใจเกี่ยวกับคุณภาพของรหัสของ SQL ความจริงที่ว่า SQL ของคุณถูกแสดงเป็นข้อความไม่ได้ทำให้การซ่อนตรรกะในฮีปของอัลกอริทึมการจัดการสตริง เป็นไปได้อย่างสมบูรณ์ที่จะเขียน SQL เป็นข้อความในลักษณะที่โปรแกรมเมอร์ของคุณสามารถอ่านได้

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

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

และสุดท้าย: ใช้ระเบียบการตั้งชื่อที่ชัดเจนสอดคล้องและใช้งานง่าย ในทำนองเดียวกับที่โค้ดที่เขียนได้ดีควรอ่านได้ SQL schema หรือแบบสอบถามที่ดีควรอ่านได้และบอกคุณได้ว่าสิ่งใดที่ทำอยู่แม้ว่าจะไม่มีความคิดเห็นก็ตาม คุณจะขอบคุณตัวเองในหกเดือนเมื่อคุณต้องบำรุงรักษาบนโต๊ะ "SELECT account_number, billing_date FROM national_accounts"ทำงานได้ง่ายกว่า "เลือก ACCNTNBR, BILLDAT จาก NTNLACCTS"

ไม่ได้ดำเนินการแบบสอบถาม SELECT ที่เกี่ยวข้องก่อนที่จะเรียกใช้แบบสอบถามลบ (โดยเฉพาะในฐานข้อมูลการผลิต)!

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

a) Hardcoding ค่าแบบสอบถามในสตริง
b) การวางรหัสแบบสอบถามฐานข้อมูลในการดำเนินการ "OnButtonPress" ในโปรแกรมประยุกต์แบบฟอร์ม Windows

ฉันเคยเห็นทั้งคู่

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

1. คิดว่าพวกเขาเป็น DBAs และนักสร้างแบบจำลองข้อมูล / นักออกแบบเมื่อพวกเขาไม่มีการปลูกฝังแบบเป็นทางการใด ๆ ในพื้นที่เหล่านั้น

2. การคิดว่าโครงการของพวกเขาไม่ต้องการ DBA เพราะทุกอย่างนั้นง่าย / ไม่สำคัญ

3. ไม่สามารถแยกแยะระหว่างงานที่ควรทำในฐานข้อมูลอย่างถูกต้องและงานที่ควรทำในแอป

4. ไม่ตรวจสอบความถูกต้องของการสำรองข้อมูลหรือไม่ทำการสำรองข้อมูล

5. ฝัง SQL ดิบในรหัสของพวกเขา

นี่คือลิงก์ไปยังวิดีโอที่เรียกว่า ' ข้อผิดพลาดในการพัฒนาฐานข้อมูลคลาสสิกและห้าวิธีในการเอาชนะ ' โดย Scott Walz

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

ไม่เข้าใจว่า DBMS ทำงานอย่างไรภายใต้ประทุน

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

โดยเฉพาะ:

1. คุณรู้หรือไม่ว่าดัชนีแบบคลัสเตอร์คืออะไร คุณคิดเกี่ยวกับมันเมื่อคุณออกแบบสคีมาของคุณหรือไม่

2. คุณรู้วิธีการใช้ดัชนีอย่างถูกต้องหรือไม่? วิธีนำดัชนีมาใช้ใหม่ได้อย่างไร คุณรู้หรือไม่ว่าดัชนีการครอบคลุมคืออะไร?

3. เยี่ยมมากคุณมีดัชนี ดัชนีของคุณมีขนาดใหญ่เพียง 1 แถว ดัชนีจะมีขนาดใหญ่แค่ไหนเมื่อคุณมีข้อมูลจำนวนมาก? ที่จะพอดีกับหน่วยความจำได้อย่างง่ายดาย? ถ้ามันจะไม่ไร้ประโยชน์มันเป็นดัชนี

4. คุณเคยใช้คำอธิบายใน MySQL หรือไม่ ยิ่งใหญ่ ตอนนี้จงซื่อสัตย์กับตัวเอง: คุณเข้าใจไหมถึงครึ่งหนึ่งของสิ่งที่คุณเห็น? ไม่คุณอาจไม่ได้ แก้ไขที่

5. คุณเข้าใจ Query Cache หรือไม่ คุณรู้หรือไม่ว่าสิ่งที่ทำให้แบบสอบถามไม่สามารถเข้าถึงได้

6. คุณใช้ MyISAM หรือไม่ หากคุณต้องการค้นหาข้อความแบบเต็ม MyISAM ก็น่าสนใจอยู่ดี ใช้สฟิงซ์ จากนั้นเปลี่ยนเป็น Inno

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