วิศวกรรมซอฟต์แวร์

ถาม - ตอบสำหรับมืออาชีพนักวิชาการและนักเรียนที่ทำงานในวงจรการพัฒนาระบบ

5
การตอบสนองต่อคำขอคุณสมบัติแอพฉันจะไม่นำ [ปิด] ไปใช้
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว ฉันเป็นนักพัฒนาแอพใหม่และหลังจากดาวน์โหลดแอปของฉันมากกว่า 20 ครั้ง (ฟรีและไม่ต้องโฆษณา) ฉันได้รับคำขอคุณสมบัติสองคำขอแล้วและฉันจะไม่ดำเนินการอย่างใดอย่างหนึ่ง ฉันควรตอบคำขอคุณสมบัติเหล่านี้หรือไม่และอย่างไร? ฉันไม่ต้องการตอบสนองเลยเพราะฉันต้องการใช้เวลาในการทำงานกับแอพของฉัน แต่การเป็นนักพัฒนาใหม่การให้คะแนนที่ไม่ดีในแอพสโตร์อาจทำให้แอปของฉันเสียหาย
10 mobile  appstore 

5
Quadtree พร้อมรายการที่ซ้ำกัน
ฉันกำลังใช้ควอดทรี สำหรับผู้ที่ไม่ทราบโครงสร้างข้อมูลนี้ฉันรวมถึงคำอธิบายเล็ก ๆ ต่อไปนี้: ควอดทรีที่มีโครงสร้างข้อมูลและอยู่ในระนาบแบบยุคลิดสิ่งที่ octree อยู่ในพื้นที่ 3 มิติ การใช้ควอดทรีทั่วไปคือการจัดทำดัชนีเชิงพื้นที่ เพื่อสรุปการทำงานของมัน quadtree คือชุดของรูปสี่เหลี่ยมที่นี่ด้วยความจุสูงสุดและกล่องขอบเขตเริ่มต้น เมื่อพยายามที่จะแทรกองค์ประกอบลงในควอดทรีซึ่งมีความจุมากที่สุดควอดทรีจะถูกแบ่งออกเป็น 4 ควอดทรี (การแสดงทางเรขาคณิตซึ่งจะมีพื้นที่เล็กกว่าต้นไม้สี่เท่าก่อนแทรก); แต่ละองค์ประกอบมีการกระจายใน subtrees ตามตำแหน่งของมันคือ มุมบนซ้ายถูกผูกไว้เมื่อทำงานกับสี่เหลี่ยม ดังนั้นควอดทรีเป็นทั้งใบและมีองค์ประกอบน้อยกว่าความสามารถของมันหรือต้นไม้ที่มี 4 ควอดทรีเป็นเด็ก ๆ ความกังวลของฉันคือถ้าคุณพยายามเพิ่มรายการที่ซ้ำกันอาจเป็นองค์ประกอบเดียวกันหลายครั้งหรือหลายองค์ประกอบที่มีตำแหน่งเดียวกัน quadtrees มีปัญหาพื้นฐานในการจัดการกับขอบ ตัวอย่างเช่นถ้าคุณทำงานกับควอดทรีที่มีความจุ 1 และหน่วยสี่เหลี่ยมผืนผ้าเป็นกล่องขอบเขต: [(0,0),(0,1),(1,1),(1,0)] และคุณลองแทรกสี่เหลี่ยมสองอันบนขอบเขตซ้ายบนซึ่งเป็นจุดกำเนิด: (หรือในทำนองเดียวกันถ้าคุณลองแทรก N + 1 ครั้งในควอดทรีที่มีความจุ N> 1) quadtree->insert(0.0, 0.0, 0.1, 0.1) quadtree->insert(0.0, 0.0, 0.1, 0.1) ส่วนแทรกครั้งแรกจะไม่มีปัญหา: แต่เมื่อแทรกครั้งแรกจะก่อให้เกิดการแบ่ง …

2
วิธีการแบบไม่มีพารามิเตอร์และว่างเปล่าใน Scala
ตอนนี้ฉันกำลังเรียน Scala ผ่าน Programming Scala (ที่ 2) ของ Odersky ฉันเกินบทที่ 10 ที่เขาเริ่มแนะนำวิธีการแบบไม่มีพารามิเตอร์และแบบไม่มีพารามิเตอร์ ฉันไม่สามารถเอาหัวไปรอบ ๆ มันได้ จนถึงตอนนี้สิ่งที่ฉันเข้าใจคือฉันควรใช้ parens ว่างถ้าวิธีการมีผลข้างเคียงและวิธีการแบบไม่มีพารามิเตอร์ ฉันไม่สามารถเข้าใจได้ว่าข้อได้เปรียบของอนุสัญญานี้คืออะไร ฉันอ่านโพสต์ใน Exchange Exchange แต่ตามจริงแล้วเมื่อโพสต์เริ่มพูดถึงหัวข้อนี้ในระดับลึกฉันก็หายไป ฉันกำลังมองหาคำอธิบายง่ายๆเกี่ยวกับกรณีการใช้งานทั่วไปสำหรับคุณสมบัติภาษานี้และข้อดีที่จะช่วยให้ฉันเข้าใจดีขึ้นคืออะไร
10 scala 

4
จงใจยกข้อยกเว้นเพื่อใช้ catch
สำหรับแบบทั่วไปที่if...elseมีการจัดการข้อยกเว้นบางอย่างเช่นตัวอย่างต่อไปนี้เป็นแนวทางปฏิบัติที่แนะนำเพื่อหลีกเลี่ยงการทำสำเนารหัสหรือไม่ try { if (GetDataFromServer()) { return ProcessData(); } else { throw new Exception(); } catch(Exception ex) { return null; } แทน... try { if (GetDataFromServer()) { return ProcessData(); } else { return null; } } catch(Exception ex) { return null; } ฉันรู้ว่ามีการแสดงเล็กน้อย แต่ฉันสงสัยว่านี่เป็นการปฏิบัติที่ยอมรับได้หรือไม่ ปัจจุบันฉันใช้วิธีที่สองโดยเฉพาะในกรณีที่ฉันต้องจัดการกับข้อยกเว้นที่แตกต่างกัน - แต่ฉันสงสัยว่าวิธีแรกนั้นเหมาะสมกับกรณีง่ายหรือไม่

3
การสืบทอด: เป็นรหัสจาก superclass จริง * คัดลอก * ไปยังคลาสย่อยหรือเป็น * อ้างถึงโดย subclass *?
ชั้นSubเป็น subclass Supของชั้นเรียน นั่นหมายความว่าในทางปฏิบัติจริง ๆ ? หรือกล่าวอีกนัยหนึ่งความหมายในทางปฏิบัติของ "การสืบทอด" คืออะไร? ตัวเลือกที่ 1:รหัสจาก Sup จะถูกคัดลอกไปยัง Sub อย่างแท้จริง (เหมือนใน 'copy-paste' แต่ไม่มีโค้ดที่คัดลอกที่มองเห็นได้ในคลาสย่อย) ตัวอย่าง: methodA()เป็นวิธีการดั้งเดิมใน Sup Sub ขยาย Sup ดังนั้นจึงmethodA()เป็น (แทบ) คัดลอกวางไปที่ Sub methodA()ตอนนี้ตมีวิธีการตั้งชื่อ มันเหมือนกับของ Sup methodA()ในทุกบรรทัดของโค้ด แต่เป็นของ Sub - ทั้งหมดและไม่ขึ้นกับ Sup หรือเกี่ยวข้องกับ Sup ในทางใดทางหนึ่ง ตัวเลือกที่ 2:รหัสจาก Sup ไม่ได้ถูกคัดลอกไปยัง Sub จริง ๆ มันยังคงอยู่ในซูเปอร์คลาสเท่านั้น แต่โค้ดนั้นสามารถเข้าถึงได้ผ่านคลาสย่อยและสามารถใช้งานได้โดยคลาสย่อย ตัวอย่าง: …

5
นักแปลคอมไพเลอร์จำเป็นต้องเข้าใจรหัสเครื่องจริงหรือไม่? [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา อาจเป็นคำถามแปลก ๆ ผู้ชายกำลังเขียนคอมไพเลอร์ C ++ (หรือภาษาที่ไม่ใช่ VM): เขาจำเป็นต้องสามารถอ่าน / เขียนภาษาเครื่องดิบได้หรือไม่? มันทำงานอย่างไร แก้ไข: ฉันหมายถึงเฉพาะผู้แปลที่รวบรวมรหัสเครื่องไม่ใช่ภาษาการเขียนโปรแกรมอื่น

12
เหตุใดภาษาจึงไม่มีความสามารถในการเปรียบเทียบค่ากับค่าอื่นมากกว่าหนึ่งค่า [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา พิจารณาสิ่งต่อไปนี้: if(a == b or c) ในภาษาส่วนใหญ่จะต้องเขียนเป็น: if(a == b or a == c) ซึ่งค่อนข้างยุ่งยากและทำซ้ำข้อมูล ฉันรู้ว่าไวยากรณ์ตัวอย่างด้านบนของฉันค่อนข้าง clunky เล็กน้อย แต่ฉันแน่ใจว่ามีวิธีที่ดีกว่าในการถ่ายทอดความคิด ทำไมไม่มีภาษาให้มากกว่านี้ มีปัญหาเรื่องประสิทธิภาพหรือไวยากรณ์หรือไม่

1
การพัฒนาโดยใช้“ รถไฟ” คืออะไร?
ฉันเจอคำศัพท์ใหม่ในวิธีการพัฒนาและฉันไม่สามารถหาคำจำกัดความได้ โดยเฉพาะเรียกว่า "การพัฒนาด้วยรถไฟ" นี่คือตัวอย่างของที่ฉันได้เห็นคำนี้ สัปดาห์ก่อนหน้านี้ฉันขอให้ผู้นำด้านวิศวกรรมและผู้จัดการปล่อยรุ่น Firefox สำหรับ Windows Metro ออกจากรถไฟ (Johnathan Nightingale) https://blog.mozilla.org/futurereleases/2014/03/14/metro/ จากเว็บไซต์อาชีพของ Mozilla: ประสบการณ์ทำงานกับทั้งวิธีการพัฒนาที่คล่องตัวและทีมพัฒนา / ฝึกอบรมโดยใช้รถไฟ ฉันเคยได้ยินเรื่อง "รถไฟ" มาก่อนและไม่ใช่แค่ในบริบทของ Mozilla แต่ฉันไม่สามารถหาข้อมูลที่ดีเกี่ยวกับมันได้ในเน็ต เมื่อฉันค้นหา "การพัฒนาซอฟต์แวร์โดยใช้รถไฟ" ฉันพบข้อมูลน้อยมากในผลการค้นหา สิ่งที่ใกล้เคียงที่สุดที่ฉันสามารถขุดได้ซึ่งแยกรถไฟออกจากเกวียนก็คือ "รถไฟ" กำลังจะทำการเผยแพร่ในช่วงเวลาปกติตามตาราง แต่ก็ดูเหมือนว่า "รถไฟ" เป็นระบบ QA ที่เป็นรูปธรรม ดังนั้น "การพัฒนาโดยใช้รถไฟ" คืออะไร?

4
ฉันควรใช้ความพยายามมากแค่ไหนในการสร้างการออกแบบที่ควบคู่กันอย่างหลวม ๆ
ปัจจุบันฉันเรียนรู้เกี่ยวกับรูปแบบการออกแบบ ฉันคิดว่าคนส่วนใหญ่ยอมรับว่ารูปแบบเหล่านี้เป็นเครื่องมือที่ยอดเยี่ยม แต่ควรใช้กับการกลั่นกรองและไม่ใช่คำตอบสำหรับทุกสิ่ง การใช้งานมากเกินไปจะทำให้แอปพลิเคชันมีความซับซ้อนมากเกินไปโดยมีประโยชน์เพียงเล็กน้อย ควรใช้รูปแบบเฉพาะที่สามารถเป็นทางออกที่ดีที่สุดหรือช่วยในการสร้างทางออกที่ดี (คุณเห็นด้วย?) ด้วยสิ่งนี้ในใจ: หนังสือที่ฉันกำลังอ่าน (รูปแบบการออกแบบหัวแรก) มักเน้นถึงความสำคัญของข้อต่อหลวมๆ การมีเพศสัมพันธ์แบบหลวมนี้ทำได้โดยทำตามหลักการเช่น 'โปรแกรมไปยังส่วนต่อประสานไม่ใช่การใช้งาน' และ 'สรุปสิ่งที่แตกต่าง' โดยพื้นฐานแล้วรูปแบบส่วนใหญ่ที่ฉันได้เรียนรู้มานั้นมีอยู่เป็นส่วนใหญ่เพื่อให้การออกแบบเป็นแบบคู่อย่างอิสระและทำให้มีความยืดหยุ่นมากขึ้น ฉันเข้าใจถึงความสำคัญและประโยชน์ของข้อต่อหลวม แต่คำถามของฉันคือต้องใช้ความพยายามมากแค่ไหนในการสร้างการออกแบบที่มีความยืดหยุ่นและหลวม ผู้ที่คัดค้านรูปแบบการออกแบบบอกว่าค่าใช้จ่ายในการใช้รูปแบบเหล่านี้มักจะมากกว่าประโยชน์ คุณลงทุนเวลามากในการสร้างการออกแบบคู่ที่หลวม ๆ โดยใช้รูปแบบที่จริงแล้ว - ข้อต่อหลวม, 'การตั้งโปรแกรมไปยังส่วนต่อประสาน, ไม่ใช่การใช้งาน' และหลักการเหล่านี้ทั้งหมด - อาจไม่สำคัญนัก สิ่งที่ฉันอยากรู้คือฉันควรใช้ความพยายามในการสร้างระดับนามธรรมและการออกแบบเพิ่มเติมเพียงใดเพื่อให้แอปพลิเคชันของฉันปฏิบัติตามหลักการ OO เช่นข้อต่อหลวมการเขียนโปรแกรมเข้าสู่อินเตอร์เฟส ฯลฯ คุ้มหรือไม่ มัน? ฉันควรใช้ความพยายามมากแค่ไหนในเรื่องนี้?

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

5
ทีมการต่อสู้ควรตอบสนองความมุ่งมั่นของ Sprint บ่อยแค่ไหน? [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา ความมุ่งมั่นเป็นสัญญาและเราทุกคนได้รับการสอนว่าคุณต้องรักษาสัญญาของคุณ แต่มันเป็นจริงหรือไม่ที่จะรักษาความมุ่งมั่นของ Sprint แต่ละตัว บางครั้งคนป่วยบางครั้งวิธีการทางเทคนิคได้รับการพิสูจน์ผิดและคุณต้องคิดใหม่ทุกอย่างบางครั้งในระหว่างการหารือเพิ่มเติมกับเจ้าของผลิตภัณฑ์หรือผู้ใช้ที่คุณเข้าใจว่าคุณลักษณะควรแตกต่างจากที่เคยคิด ฉันรู้ว่าคู่มือการต่อสู้อย่างเป็นทางการตอนนี้ใช้คำว่า "คาดการณ์" มากกว่าความมุ่งมั่นอาจจะแก้ปัญหาเหล่านี้ได้ ดังนั้นคำถามของฉันคือบ่อยแค่ไหนที่ทีมในองค์กรของคุณรักษาความมุ่งมั่นและไม่ว่าคุณจะชอบแนวทางนี้หรือคุณต้องการเปลี่ยน ขอบคุณ.
10 scrum 

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

1
“ เทมเพลต C ++: คู่มือฉบับสมบูรณ์” (c) 2002 - รุ่นล่าสุดด้วย C ++ 11?
เทมเพลต C ++หนังสือ: คู่มือฉบับสมบูรณ์ , (c) 2002, ดูน่าสนใจสำหรับฉันมาก, แต่เนื่องจากอายุ 12 ปี, ฉันกังวลว่ามันอาจล้าสมัย มีบทวิจารณ์ของ Amazon ที่ได้รับความนิยมสูงเมื่อเร็ว ๆ นี้เมื่อปีที่แล้วและฉันไม่เห็นชื่อเรื่องล่าสุดในเทมเพลต C ++ ไม่มีใครรู้ว่าหนังสือเกี่ยวกับเทมเพลตที่ตีพิมพ์ในปี 2002 (ตรงข้ามกับหนังสือโดยเฉพาะเกี่ยวกับ STL) จะมีไวยากรณ์หรือแนวคิดที่ถูกแทนที่หรือเพิ่มโดยพูด C ++ 11 ไหม ต่อไปนี้มาจากคำอธิบายหนังสือของ Amazon : เทมเพลตเป็นหนึ่งในคุณสมบัติที่ทรงพลังที่สุดของ C ++ แต่บ่อยครั้งที่พวกเขาถูกทอดทิ้งถูกเข้าใจผิดและใช้ผิดประเภท เทมเพลต C ++: คู่มือฉบับสมบูรณ์ช่วยให้สถาปนิกและวิศวกรซอฟต์แวร์เข้าใจอย่างชัดเจนว่าทำไมเมื่อใดและอย่างไรถึงจะใช้เทมเพลตเพื่อสร้างและบำรุงรักษาซอฟต์แวร์ที่สะอาดขึ้นเร็วขึ้นและชาญฉลาดยิ่งขึ้น เทมเพลต C ++ เริ่มต้นด้วยการสอนที่ลึกซึ้งเกี่ยวกับแนวคิดพื้นฐานและคุณสมบัติด้านภาษา ส่วนที่เหลือของหนังสือเล่มนี้เป็นข้อมูลอ้างอิงที่ครอบคลุมโดยมุ่งเน้นที่รายละเอียดภาษาก่อนจากนั้นจึงใช้เทคนิคการเข้ารหัสที่หลากหลายและในที่สุดแอปพลิเคชันขั้นสูงสำหรับแม่แบบ ตัวอย่างที่ใช้ในหนังสือแสดงแนวคิดที่เป็นนามธรรมและแสดงให้เห็นถึงแนวปฏิบัติที่ดีที่สุด ผู้อ่านเรียนรู้ พฤติกรรมที่แน่นอนของแม่แบบ วิธีหลีกเลี่ยงข้อผิดพลาดที่เกี่ยวข้องกับแม่แบบ สำนวนและเทคนิคต่าง ๆ …
10 c++  templates 

2
การทดสอบหน่วยผลรหัสหนักด้าน
ฉันเริ่มเขียนรหัส C ++ เพื่อเรียกใช้หุ่นยนต์และฉันไม่ทราบวิธีรวมการทดสอบหน่วยหากฉันสามารถทำได้ ฉันได้รับห้องสมุดที่อนุญาตให้สร้าง "คำสั่ง" สำหรับหุ่นยนต์ซึ่งมีกำหนดและดำเนินการโดยอัตโนมัติ กลไกในการสร้างคำสั่งเหล่านี้เป็นประเภทรองชั้นฐานคำสั่งพวกเขาให้และดำเนินการเสมือนvoid Initialize(), void Execute()และvoid End()วิธีการ ฟังก์ชั่นเหล่านี้ทำงานอย่างหมดจดสำหรับผลข้างเคียงซึ่งทำสิ่งต่าง ๆ กับหุ่นยนต์ (วิ่งมอเตอร์ยืดลูกสูบ ฯลฯ ) ด้วยเหตุนี้ฉันไม่เห็นที่ใดก็ได้ในการแนบการทดสอบหน่วยกับโค้ดขาดการเยาะเย้ยห้องสมุดทั้งหมดเพื่อให้ฉันสามารถตรวจสอบเสมือนก่อนและหลังสถานะของหุ่นยนต์ มีวิธีทดสอบหน่วยที่ไม่เป็นภาระมากเกินไปหรือไม่ แก้ไข ฉันคิดว่าฉันเข้าใจผิดเกี่ยวกับการทำงานของห้องสมุด ห้องสมุดมีส่วนต่อประสานกับหุ่นยนต์เป็นส่วนใหญ่รวมถึงระบบคำสั่ง / การตั้งเวลาดังนั้นมันจึงไม่ง่ายเท่ากับการเยาะเย้ยคลาสฐานคำสั่ง ฉันโชคไม่ดีที่ไม่มีเวลาทำเช่นนั้น

2
ต้องการฐานข้อมูลการทำให้เป็นมาตรฐานกับความโปร่งใสของสคีมาหรือไม่
ความต้องการใหม่ได้ปรากฏขึ้นบน codebase เก่าซึ่งโดยทั่วไปจะช่วยให้การสื่อสารโดยตรง (ภายใน) ระหว่างสองคลาสก่อนหน้านี้ไม่เกี่ยวข้องโดยตรงของผู้ใช้ (เก็บไว้ในตารางที่แตกต่างกับสคีมาที่แตกต่างกันโดยสิ้นเชิงและเศร้ารหัสแทบไม่ทราบ ออกแบบน้อยดังนั้นจึงไม่มีชั้นผู้ปกครอง) เนื่องจากเราออกไปแขวนกระเป๋าในการตั้งค่าแบบเก่าที่ไม่เคยพิจารณาฟังก์ชั่นนี้มาก่อนจึงไม่มีการรับประกันว่าจะไม่มีการชนกันของ PK - เนื่องจากชุดข้อมูลที่ใช้อยู่นั้นรับประกันว่าจะมี ดังนั้นวิธีการแก้ปัญหาที่เห็นได้ชัด: ฆ่ามันด้วยไฟและเขียนตารางการทำแผนที่ทั้งหมดของระเบียบ ฉันได้รับสองทิศทางสำหรับวิธีที่เป็นไปได้ในการนำแผนที่ไปใช้ แต่ฉันไม่ใช่ DBA ดังนั้นฉันจึงไม่แน่ใจว่ามีข้อดีหรือข้อเสียใดที่ฉันพลาดไป เพื่อความกระจ่างเกี่ยวกับสิ่งที่เป็นนามธรรมให้พิจารณาสามกลุ่มข้อมูลผู้ใช้ที่แตกต่างกัน: อาจารย์ผู้บริหารนักเรียน (ไม่นี่ไม่ใช่การบ้านที่ได้รับมอบหมายสัญญา!) การทำแผนที่ 1 (Professor_id, admin_id และ student_id เป็นรหัสต่างประเทศในตารางที่เกี่ยวข้อง) | mailing_id (KEY) | professor_id | admin_id | student_id | ------------------------------------------------------- | 1001 | NULL | 87 | NULL | | 1002 | …

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