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

แนวคิดที่สำคัญที่นักพัฒนาซอฟต์แวร์และผู้เชี่ยวชาญด้านซอฟต์แวร์อื่น ๆ ควรทราบเกี่ยวกับฐานข้อมูลคืออะไร

แนวทางการตอบสนอง:

ทำให้รายการของคุณสั้น
หนึ่งแนวคิดต่อคำตอบนั้นดีที่สุด

เฉพาะเจาะจง
"การสร้างแบบจำลองข้อมูล" อาจเป็นทักษะที่สำคัญแต่นั่นหมายความว่าอย่างไร

อธิบายเหตุผลของคุณ
เหตุใดแนวคิดของคุณจึงสำคัญ อย่าพูดว่า "ใช้ดัชนี" อย่าตกเป็น "แนวปฏิบัติที่ดีที่สุด" โน้มน้าวใจผู้ฟังของคุณให้เรียนรู้เพิ่มเติม

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

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

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

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

ในช่วง 15 ปีที่ผ่านมามีการใช้ฐานข้อมูลเพื่อจัดเก็บข้อมูลถาวรที่เกี่ยวข้องกับแอปพลิเคชันเดียว การสร้างฐานข้อมูลสำหรับMySQLหรือAccessหรือSQL Serverกลายเป็นกิจวัตรประจำวันจนฐานข้อมูลเกือบจะกลายเป็นส่วนหนึ่งของแอปพลิเคชันทั่วไป บางครั้งภารกิจ จำกัด เริ่มต้นจะถูกผลักดันโดยการคืบของภารกิจเนื่องจากมูลค่าที่แท้จริงของข้อมูลกลายเป็นชัดเจน น่าเสียดายที่ฐานข้อมูลที่ออกแบบมาเพื่อจุดประสงค์เดียวมักจะล้มเหลวอย่างมากเมื่อพวกเขาเริ่มถูกผลักดันให้เข้าสู่บทบาทที่มีทั้งองค์กรและภารกิจสำคัญ

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

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

การสร้างแบบจำลองข้อมูลแนวคิดเป็นการวิเคราะห์ความต้องการจากมุมมองข้อมูลเป็นศูนย์กลาง

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

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

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

ในที่สุดใครก็ตามที่ยุ่งกับฐานข้อมูลต้องเข้าใจว่าค่าของข้อมูลมักจะอยู่ได้นานกว่าระบบที่ถูกดักจับ

ต๊าย!

คำถามที่ดี. ต่อไปนี้เป็นความคิดบางอย่างที่ไม่มีลำดับเฉพาะ:

1. การทำให้เป็นมาตรฐานอย่างน้อยรูปแบบปกติที่สองนั้นเป็นสิ่งจำเป็น

2. ความสมบูรณ์ของการอ้างอิงก็เป็นสิ่งจำเป็นเช่นกันด้วยการพิจารณาลบและปรับปรุงอย่างเหมาะสม

3. การใช้ข้อ จำกัด การตรวจสอบที่ดีและเหมาะสม ให้ฐานข้อมูลทำงานได้มากที่สุด

4. อย่ากระจายตรรกะทางธุรกิจทั้งในฐานข้อมูลและรหัสชั้นกลาง เลือกอย่างใดอย่างหนึ่งโดยเฉพาะอย่างยิ่งในรหัสชั้นกลาง

5. ตัดสินใจเลือกวิธีการที่สอดคล้องกันสำหรับคีย์หลักและคีย์แบบคลัสเตอร์

6. ไม่ทำดัชนีมากกว่า เลือกดัชนีของคุณอย่างชาญฉลาด

7. การตั้งชื่อตารางและคอลัมน์ที่สอดคล้องกัน เลือกมาตรฐานและติดมัน

8. จำกัด จำนวนคอลัมน์ในฐานข้อมูลที่จะยอมรับค่า Null

9. อย่านำตัวไปด้วย พวกเขามีการใช้งาน แต่สามารถทำให้สิ่งต่าง ๆ อย่างเร่งด่วน

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

11. รับหนังสือของ Celko เกี่ยวกับการออกแบบฐานข้อมูล ผู้ชายคนนี้หยิ่ง แต่รู้เรื่องของเขา

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

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

ประการที่สามนักพัฒนาจำเป็นต้องเข้าใจ SQL พื้นฐานรวมถึงการรวม

ที่ผ่านมานี้ขึ้นอยู่กับว่านักพัฒนามีส่วนร่วมอย่างไร ฉันได้ทำงานในตำแหน่งที่ฉันเป็นนักพัฒนาและพฤตินัย DBA ที่ DBAs เพิ่งเดินไปตามทางเดินและที่ DBA ถูกปิดในพื้นที่ของตัวเอง (ฉันไม่ชอบอันดับที่สาม) สมมติว่านักพัฒนามีส่วนร่วมในการออกแบบฐานข้อมูล:

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

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

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

พวกเขาควรมีความรู้พื้นฐานเกี่ยวกับวิธีการวางแผนและวิธีการอ่านโดยทั่วไป (อย่างน้อยก็เพียงพอที่จะบอกได้ว่าอัลกอริทึมนั้นมีประสิทธิภาพหรือไม่)

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

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

ฉันลืมอะไรไปอย่างไม่ต้องสงสัย แต่ผู้พัฒนาโดยเฉลี่ยไม่จำเป็นต้องเป็น DBA หากมี DBA จริงอยู่ในมือ

การจัดทำดัชนีพื้นฐาน

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

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

ผู้ออกแบบควรตระหนักถึงรูปแบบการต่อต้านดัชนีทั่วไปเช่น:

• Access anti-pattern (การทำดัชนีทุกคอลัมน์หนึ่งต่อหนึ่ง)
• Anti-All-pattern-anti (ดัชนีขนาดใหญ่หนึ่งรายการในคอลัมน์ทั้งหมดหรือส่วนใหญ่ถูกสร้างขึ้นภายใต้การแสดงผลที่เข้าใจผิดว่าจะเพิ่มความเร็วในการค้นหาที่เป็นไปได้ทั้งหมดที่เกี่ยวข้องกับคอลัมน์ใด ๆ เหล่านั้น)

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

normalization

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

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

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

ดัชนีทำงานอย่างไร

อาจไม่ใช่หัวข้อที่สำคัญที่สุด แต่แน่นอนว่าหัวข้อที่ถูกประเมินต่ำที่สุด

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

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

นั่นเป็นเพราะฐานข้อมูล SQL ทำงานได้ดีมากในฐานะแบล็กบ็อกซ์:

บอกสิ่งที่คุณต้องการ (gimme SQL) ฉันจะดูแลมัน

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

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

นั่นเป็นเหตุผลที่ผมเชื่อว่าการจัดทำดัชนีเป็นหัวข้อฉบับที่ 1 จะไม่ลืมเมื่อทำงานกับฐานข้อมูล น่าเสียดายที่ลืมง่ายมาก

คำปฏิเสธ

ข้อโต้แย้งที่ยืมมาจากคำนำของ eBook ฟรีของฉัน " ใช้ดัชนีลุค " ฉันใช้เวลาค่อนข้างมากในการอธิบายว่าดัชนีทำงานอย่างไรและใช้งานอย่างไรให้เหมาะสม

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

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

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

หลีกเลี่ยงการฉีดSQL และวิธีรักษาความปลอดภัยฐานข้อมูลของคุณ

นักพัฒนาทุกคนควรรู้ว่าสิ่งนี้เป็นเท็จ: "การรวบรวมโปรไฟล์การดำเนินการฐานข้อมูลแตกต่างจากรหัสการทำโปรไฟล์"

มี Big-O ที่ชัดเจนในความหมายดั้งเดิม เมื่อคุณทำEXPLAIN PLAN(หรือเทียบเท่า) คุณจะเห็นอัลกอริทึม อัลกอริทึมบางตัวเกี่ยวข้องกับลูปซ้อนกันและเป็นO ( n ^ 2) อัลกอริทึมอื่น ๆ เกี่ยวข้องกับการค้นหา B-tree และเป็นO ( n log n )

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

หากคุณไม่ชัดเจนเกี่ยวกับอัลกอริทึมที่ใช้ให้ทำดังต่อไปนี้ หยุด. อธิบายแผนการดำเนินการแบบสอบถาม ปรับดัชนีตาม

นอกจากนี้ยังมีข้อสรุป: ดัชนีเพิ่มเติมไม่ดีขึ้น

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

ผมคิดว่านักพัฒนาทุกคนควรเข้าใจว่าฐานข้อมูลที่จำเป็นต้องมีกระบวนทัศน์ที่แตกต่างกัน

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

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

อีกสิ่งที่นักพัฒนาควรเข้าใจคือมีสามสิ่งที่คุณควรคำนึงถึงเมื่อออกแบบฐานข้อมูล:

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

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

3. ความปลอดภัย - ข้อมูลนี้เป็นเลือดชีวิตของ บริษัท ของคุณมันยังมีข้อมูลส่วนบุคคลที่ถูกขโมยบ่อยๆ เรียนรู้วิธีปกป้องข้อมูลของคุณจากการโจมตีการฉีด SQL และการฉ้อโกงและการขโมยข้อมูลประจำตัว

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

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

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

อย่าพัฒนาในฐานข้อมูลเวอร์ชันที่ใหม่กว่าเวอร์ชันการผลิต ไม่เคยไม่เคยไม่เคยพัฒนาโดยตรงกับฐานข้อมูลการผลิต

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

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

การออกแบบฐานข้อมูลเชิงวิวัฒนาการ http://martinfowler.com/articles/evodb.html

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

นักพัฒนาควรรู้ว่าจะต้องสร้างฐานข้อมูลการผลิตใหม่อีกครั้งในแง่ของการควบคุมเวอร์ชันการรวมอย่างต่อเนื่องและการทดสอบอัตโนมัติ

กระบวนการออกแบบฐานข้อมูลวิวัฒนาการมีแง่มุมของการบริหารจัดการตัวอย่างเช่นคอลัมน์จะถูกดร็อปหลังจากช่วงเวลาชีวิตในฐานข้อมูลทั้งหมดของโค๊ดฐานนี้

อย่างน้อยก็ทราบว่ามีแนวคิดและวิธีการในการสร้างฐานข้อมูลขึ้นใหม่ http://www.agiledata.org/essays/databaseRefactoringCatalog.html

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

จากประสบการณ์ของฉันกับฐานข้อมูลเชิงสัมพันธ์ผู้พัฒนาทุกคนควรรู้:

- ประเภทข้อมูลที่แตกต่าง :

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

- เรียนรู้เกี่ยวกับ 1xM และ MxM :

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

- หลักการ " KISS " นำไปใช้กับ DB เช่นกัน :

ความเรียบง่ายใช้งานได้ดีที่สุดเสมอ หากคุณได้ศึกษาว่า DB ทำงานอย่างไรคุณจะหลีกเลี่ยงความซับซ้อนที่ไม่จำเป็นซึ่งจะนำไปสู่ปัญหาการบำรุงรักษาและความเร็ว

- ดัชนี :

มันไม่เพียงพอถ้าคุณรู้ว่าพวกเขาคืออะไร คุณต้องเข้าใจว่าจะใช้เมื่อใดและเมื่อใด

เพิ่มเติม:

• พีชคณิตแบบบูลคือเพื่อนของคุณ
• รูปภาพ: อย่าเก็บไว้ในฐานข้อมูล อย่าถามว่าทำไม
• ทดสอบ DELETE ด้วย SELECT

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

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

เกี่ยวกับความคิดเห็นต่อคำตอบของ Walter M. :

"เขียนได้ดีมาก! และมุมมองทางประวัติศาสตร์นั้นยอดเยี่ยมสำหรับผู้ที่ไม่ได้ทำงานฐานข้อมูลในเวลานั้น (เช่นฉัน)"

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

สำหรับคำถามตัวเอง:

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

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

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

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

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

เคารพง่าย

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

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

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

อย่าแทรกข้อมูลด้วยการเข้ารหัสข้อความที่ผิด

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

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

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

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

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

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

รู้ขั้นตอนการประมวลผลเอ็นจินฐานข้อมูลของคุณและวางแผน

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

C ++ geek ทุกคนเขียนคลาสสตริงในวิทยาลัย กราฟิกทุกคนเกินบรรยายเขียน raytracer ในวิทยาลัย เว็บ geek ทุกคนเขียนเว็บไซต์อินเทอร์แอคทีฟ (ปกติก่อนที่เราจะมี "web frameworks") ในวิทยาลัย ฮาร์ดแวร์ทุกอัน (และแม้แต่ซอฟท์แวร์ผู้ใช้) สร้างซีพียูในวิทยาลัย แพทย์ทุกคนผ่าศพทั้งหมดในวิทยาลัยแม้ว่าเธอจะรับความดันโลหิตของฉันและบอกว่าคอเลสเตอรอลของฉันสูงเกินไปในวันนี้ ทำไมฐานข้อมูลจะแตกต่างกันอย่างไร

โชคไม่ดีที่วันนี้พวกเขาดูแตกต่างไป ผู้คนต้องการโปรแกรมเมอร์ NET เพื่อทราบวิธีการทำงานในสาย Cแต่ internals ของ RDBMS ของคุณไม่ควรกังวลคุณมากเกินไป

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

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

ลำดับของคอลัมน์ในดัชนีที่ไม่ซ้ำมีความสำคัญ

คอลัมน์แรกควรเป็นคอลัมน์ที่มีความแปรปรวนมากที่สุดในเนื้อหา (เช่นความเป็นหัวใจ)

นี่คือเพื่อช่วยความสามารถของ SQL Server ในการสร้างสถิติที่เป็นประโยชน์ในการใช้ดัชนีตอนรันไทม์

ทำความเข้าใจกับเครื่องมือที่คุณใช้ในการเขียนโปรแกรมฐานข้อมูล !!!

ฉันเสียเวลามากมายในการพยายามทำความเข้าใจว่าทำไมรหัสของฉันจึงล้มเหลวอย่างลึกลับ

ตัวอย่างเช่นถ้าคุณใช้. NET คุณจำเป็นต้องรู้วิธีใช้วัตถุในSystem.Data.SqlClientเนมสเปซอย่างเหมาะสม คุณจำเป็นต้องรู้วิธีการจัดการSqlConnectionวัตถุของคุณเพื่อให้แน่ใจว่าพวกเขาจะเปิดปิดและเมื่อจำเป็นกำจัดอย่างถูกต้อง

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

• ทักษะพื้นฐาน SQL
• การจัดทำดัชนี
• จัดการกับสาขาที่แตกต่างของ DATE / TIME / TIMESTAMP
• เอกสารคู่มือไดรเวอร์ JDBCสำหรับแพลตฟอร์มที่คุณใช้
• จัดการกับประเภทข้อมูลไบนารี ( CLOB , BLOBฯลฯ )

สำหรับบางโครงการและโมเดลเชิงวัตถุจะดีกว่า

สำหรับโครงการอื่น ๆ โมเดลเชิงสัมพันธ์จะดีกว่า

ปัญหาความต้านทานไม่ตรงกันและรู้ข้อบกพร่องทั่วไปหรือ ORMs

ความเข้ากันได้ RDBMS

ดูว่าจำเป็นต้องใช้แอปพลิเคชันใน RDBMS มากกว่าหนึ่งหรือไม่ ถ้าใช่อาจจำเป็นต้อง:

• หลีกเลี่ยงส่วนขยาย RDBMS SQL
• กำจัดทริกเกอร์และขั้นตอนการจัดเก็บ
• ปฏิบัติตามมาตรฐาน SQL ที่เข้มงวด
• แปลงชนิดข้อมูลภาคสนาม
• เปลี่ยนระดับการแยกธุรกรรม

มิฉะนั้นคำถามเหล่านี้ควรได้รับการปฏิบัติแยกต่างหากและจะมีการพัฒนาเวอร์ชันต่าง ๆ (หรือการกำหนดค่า) ของแอปพลิเคชัน

ไม่ต้องพึ่งพาลำดับของแถวที่ส่งคืนโดยแบบสอบถาม SQL

http://www.reddit.com/r/programming/comments/azdd7/programmers_sit_your_butt_down_i_need_to_have_a/