คำถามติดแท็ก refactoring

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

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

1
วิธีการสร้าง Python“ god class” ใหม่ได้อย่างไร
ปัญหา ฉันกำลังทำงานในโครงการงูหลามซึ่งชั้นเรียนหลักเป็น“ พระเจ้าวัตถุ ” เล็กน้อย นอกจากนี้เพื่อให้ friggin' หลายลักษณะและวิธีการ! ฉันต้องการปรับโครงสร้างห้องเรียนอีกครั้ง จนถึงตอนนี้ ... สำหรับขั้นตอนแรกฉันต้องการทำสิ่งที่ค่อนข้างง่าย แต่เมื่อฉันลองใช้วิธีที่ตรงไปตรงมาที่สุดมันก็ทำลายการทดสอบและตัวอย่างที่มีอยู่ โดยทั่วไปชั้นเรียนมีรายการคุณลักษณะที่ยาวมาก - แต่ฉันสามารถมองข้ามพวกเขาอย่างชัดเจนและคิดว่า“ คุณลักษณะทั้ง 5 นี้เกี่ยวข้องกัน… 8 สิ่งเหล่านี้สัมพันธ์กัน…แล้วก็มีส่วนที่เหลือ” getattr โดยทั่วไปฉันแค่ต้องการจัดกลุ่มคุณลักษณะที่เกี่ยวข้องลงในคลาสผู้ช่วยแบบ dict ฉันมีความรู้สึก__getattr__จะเหมาะสำหรับงาน ดังนั้นฉันจึงย้ายคุณสมบัติไปยังชั้นเรียนอื่นและแน่นอน__getattr__ใช้เวทย์มนตร์ของมันได้อย่างสมบูรณ์แบบดี ... ในตอนแรก แต่จากนั้นฉันลองใช้หนึ่งในตัวอย่าง คลาสย่อยตัวอย่างพยายามตั้งค่าหนึ่งในแอ็ตทริบิวต์เหล่านี้โดยตรง (ที่ระดับคลาส ) แต่เนื่องจากแอตทริบิวต์ไม่ได้“ อยู่ในสภาพร่างกาย” อีกต่อไปในชั้นผู้ปกครองฉันได้รับข้อผิดพลาดที่บอกว่าไม่มีแอตทริบิวต์ @property ฉันอ่านเกี่ยวกับ@propertyมัณฑนากร แต่ฉันก็อ่านด้วยว่ามันสร้างปัญหาให้กับคลาสย่อยที่ต้องการทำself.x = blahเมื่อxเป็นคุณสมบัติของคลาสพาเรนต์ ที่ต้องการอยากมี ให้รหัสลูกค้าทั้งหมดยังคงใช้งานได้ต่อไปself.whateverแม้ว่าwhateverคุณสมบัติของผู้ปกครองจะไม่“ อยู่ตามร่างกาย” ในคลาส (หรืออินสแตนซ์) เอง จัดกลุ่มแอตทริบิวต์ที่เกี่ยวข้องลงในคอนเทนเนอร์เหมือน dict ลดเสียงดังสุด ๆ …

7
การปรับเปลี่ยนรหัสและการปรับให้เหมาะสมนั้นควรอยู่ที่ไหนภายในระยะเวลากระบวนการที่คล่องตัวและน้ำตก
ดูเหมือนจะมีความคิดนี้ในทีมผู้บริหารโครงการที่ระบุว่า "ใช้งานได้" หมายความว่าควรถือว่าเสร็จสมบูรณ์ 100% โปรแกรมเมอร์ส่วนใหญ่รู้ว่าไม่เป็นเช่นนั้นเสมอไป หากฉันลองใช้วิธีอื่นในการทำให้ฟังก์ชั่นการทำงานนั้นไม่ได้แปลว่าฉันได้พบโซลูชันที่ดีที่สุดแล้วหรือไม่ต้องทำงานซ้ำหลังจากตรวจสอบกับผู้พัฒนารายอื่น ฉันมักจะทำอะไรสักอย่างถอยกลับแล้วถามตัวเองว่าฉันจะทำอะไรได้ดีกว่านี้หลังจากกฎเกณฑ์ทางธุรกิจพอใจ เวลา "ฉันทำได้ดีกว่านี้" ควรพอดีกับที่ใดที่หนึ่งในไทม์ไลน์หรือไม่ ฉันเห็นว่าวิธีที่ดีที่สุดคือคุณทิ้งโค้ดไว้ดีกว่าเมื่อคุณพบมัน (ในระดับหนึ่ง) ซึ่งอาจหมายถึงการเปิดตัวการโพสต์ใหม่ อย่างไรก็ตาม

4
ฉันจำเป็นต้องอัพเกรด log4j เป็น slf4j [ปิด]
ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน5 ปีที่ผ่านมา เรากำลังตรวจสอบเว็บแอปพลิเคชัน JEE ของเราเพื่อทำการรีแฟคเตอร์ตามแผนและหนึ่งในข้อเสนอแนะคือการแทนที่log4jด้วยlogbackหรือslf4j ทีมไม่ชัดเจนว่าเราควรทำเช่นนี้หรือไม่ - เนื่องจากในปัจจุบันเราต้องการติดตามหากมันยังไม่พังอย่าแก้ไขในส่วนนี้ แก้ไข:ฉันไม่ได้ขอให้เปรียบเทียบเฟรมเวิร์กการบันทึก แต่ไม่ว่าจะเป็นองค์ประกอบการรีแฟคเตอร์ที่มีคุณค่าเพื่อเปลี่ยนเฟรมเวิร์กหรือไม่เมื่อเราพอใจกับ log4j

3
แนวทางปฏิบัติที่ดีที่สุดสำหรับการเปลี่ยนชื่อสร้างใหม่และทำลายการเปลี่ยนแปลงกับทีม
แนวทางปฏิบัติที่ดีที่สุดสำหรับการ refactor และการเปลี่ยนชื่อในสภาพแวดล้อมของทีมมีอะไรบ้าง ฉันนำเรื่องนี้มาพิจารณากับสถานการณ์บางอย่าง: หากไลบรารีที่มีการอ้างอิงโดยทั่วไปนั้นถูก refactored เพื่อแนะนำการเปลี่ยนแปลงที่เกิดขึ้นกับไลบรารีหรือโครงการใด ๆ ที่อ้างอิงมัน เช่นการเปลี่ยนชื่อของวิธีการโดยพลการ หากโครงการถูกเปลี่ยนชื่อและโซลูชั่นจะต้องสร้างใหม่ด้วยการอ้างอิงการปรับปรุงให้พวกเขา หากโครงสร้างโครงการเปลี่ยนเป็น "จัดระเบียบมากขึ้น" โดยแนะนำโฟลเดอร์และย้ายโครงการหรือโซลูชันที่มีอยู่ไปยังตำแหน่งใหม่ ความคิด / คำถามเพิ่มเติมบางอย่าง: การเปลี่ยนแปลงในเรื่องนี้หรือความเจ็บปวดที่เกิดขึ้นบ่งบอกถึงโครงสร้างที่ผิดปกติหรือไม่? ใครควรรับผิดชอบในการแก้ไขข้อผิดพลาดที่เกี่ยวข้องกับการเปลี่ยนแปลงที่ผิดพลาด? หากผู้พัฒนาทำการเปลี่ยนแปลงที่ไม่เหมาะสมพวกเขาควรรับผิดชอบในการเข้าไปในโครงการที่ได้รับผลกระทบและอัปเดตพวกเขาหรือพวกเขาควรเตือนผู้พัฒนารายอื่นและแจ้งให้พวกเขาเปลี่ยนแปลงสิ่งต่างๆ นี่เป็นสิ่งที่สามารถทำได้ตามกำหนดเวลาหรือเป็นสิ่งที่ควรทำบ่อยที่สุดเท่าที่จะทำได้? หากการรีฟอร์เรชั่นถูกเลื่อนออกไปนานเกินไปมันก็ยากที่จะกระทบยอด แต่ในเวลาเดียวกันในแต่ละวันใช้เวลาเพิ่มขึ้น 1 ชั่วโมงในการแก้ไขงานสร้างเนื่องจากการเปลี่ยนแปลงเกิดขึ้นที่อื่น นี่เป็นเรื่องของกระบวนการสื่อสารที่เป็นทางการหรือเป็นอินทรีย์หรือไม่?

7
ฉันจะใช้วิธีการใดเพื่อลดโอกาสที่จะแนะนำบั๊กใหม่ ๆ ในแอพที่ซับซ้อนแบบเก่า?
ที่ทำงานฉันมักจะต้องพัฒนา (และแก้ไขข้อผิดพลาด) ในระบบเก่า (.NET 1) รหัส whos เป็นสปาเก็ตตี้ที่สมบูรณ์ - ด้วยความคิดเพียงเล็กน้อยที่กำหนดให้กับชื่อตัวแปรโครงสร้างของโปรแกรมและความคิดเห็น ด้วยเหตุนี้มันทำให้ฉันอายุมากขึ้นที่จะเข้าใจว่าต้องเปลี่ยนบิตใดและฉันมักจะ 'ทำลาย' ซอฟต์แวร์ที่มีอยู่เพราะฉันได้ทำการดัดแปลง ผมจริงๆต้องการที่จะใช้ไม่กี่เดือน (กับเพื่อนร่วมงานบริการ) จะผ่านมันไป refactor แต่ที่มีอยู่พัฒนาทั้งสองไม่สามารถเห็นความจำเป็น - ไม่คิดว่าเวลาเอาใจใส่ในการนี้ (ระบบเป็นจำนวนมาก) ฉันกลัวที่จะต้องทำงานกับรหัสเพราะต้องใช้เวลาหลายวันในการแก้ไขบางอย่างเท่านั้นเพื่อตรวจสอบว่าฉันพังอย่างอื่นแล้ว สิ่งนี้ทำให้ฉันดูไร้ความสามารถ - ดังนั้นฉันจะจัดการกับสิ่งนี้ได้อย่างไร

3
ฉันจะฝึกรูปแบบการออกแบบและการปรับโครงสร้างใหม่ด้วยวิธีที่รอบคอบได้อย่างไร [ปิด]
ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน4 ปีที่แล้ว ฉันกำลังอ่านหนังสือRefactoring เกี่ยวกับรูปแบบและสงสัยว่าฉันจะมีโอกาสฝึกฝนทักษะได้อย่างไรเพราะหากไม่มีการฝึกฝนอย่างรอบคอบเกี่ยวกับวิธีการใหม่ในการสร้างและใช้รูปแบบทักษะของฉันจะไม่ดีขึ้น แต่งานในสำนักงานกำหนดให้ฉันต้องทำภารกิจให้เสร็จโดยเร็วที่สุด ส่วนใหญ่การออกแบบและสถาปัตยกรรมของโครงการไม่ได้ถูกควบคุมโดยฉันฉันสามารถทำตามสไตล์ที่คล้ายกันเป็นรหัสที่มีอยู่เท่านั้น บางครั้งมีโครงการที่มีการออกแบบไม่ดี แต่ก็มีนักพัฒนาอีกคนหนึ่งที่มีทักษะการออกแบบดีกว่าฉันและเขามีแผนทั้งหมดในการปรับโครงสร้างโครงการอีกครั้งดังนั้นฉันจึงเพิ่งทำตามแผนของเขา ฉันจะมีโอกาสฝึกฝนได้อย่างไร

4
การปรับโครงสร้างใหม่ - เหมาะสมหรือไม่ที่จะเขียนรหัสใหม่อีกครั้งตราบใดที่การทดสอบทั้งหมดผ่าน?
ฉันเพิ่งดู"ทุกสิ่งเล็ก ๆ น้อย ๆ "จาก RailsConf 2014 ในระหว่างการพูดคุยนี้ Sandi Metz refactors ฟังก์ชั่นที่รวมถึงคำสั่ง if ซ้อนขนาดใหญ่: def tick if @name != 'Aged Brie' && @name != 'Backstage passes to a TAFKAL80ETC concert' if @quality > 0 if @name != 'Sulfuras, Hand of Ragnaros' @quality -= 1 end end else ... end ... …

5
การปรับเปลี่ยนวิธีการแบบยาว: ออกตามที่เป็นเทียบกับการแยกออกเป็นวิธีการเปรียบเทียบกับการใช้ฟังก์ชันในเครื่อง
สมมติว่าฉันมีวิธียาวเช่นนี้ public void SomeLongMethod() { // Some task #1 ... // Some task #2 ... } วิธีนี้ไม่มีชิ้นส่วนซ้ำ ๆ ที่ควรเคลื่อนย้ายไปยังวิธีอื่นหรือฟังก์ชั่นในเครื่อง มีหลายคน (รวมถึงฉัน) ที่คิดว่าวิธีการที่ยาวนานนั้นเป็นกลิ่นรหัส นอกจากนี้ผมไม่ชอบความคิดของการใช้#region(s) ที่นี่มีคำตอบที่เป็นที่นิยมมากอธิบายว่าทำไมนี้ไม่ดี แต่ถ้าฉันแยกรหัสนี้เป็นวิธีการ public void SomeLongMethod() { Task1(); Task2(); } private void Task1() { // Some task #1 ... } private void Task2() { // Some task #1 …

1
กำลังมองหาวิธีที่ดีกว่าในการรวมการปรับโครงสร้างเชิงลึกเข้ากับการพัฒนาตามคุณลักษณะ
คำชี้แจงปัญหา: ได้รับ: TFS เป็นการควบคุมแหล่งที่มา แอปพลิเคชันไคลเอนต์บนเดสก์ท็อปจำนวนมากที่มีรหัสดั้งเดิมที่มีการออกแบบสถาปัตยกรรมไม่ดีหรือขาดหายไป ลูกค้าต้องการคุณสมบัติใหม่ ๆ อย่างต่อเนื่องพร้อมคุณภาพเสียง การจัดส่งที่รวดเร็วและการบ่นกับ UI ที่ไม่เป็นมิตรของผู้ใช้ ปัญหา: แอปพลิเคชันต้องมีการปรับโครงสร้างอย่างล้ำลึก กระบวนการนี้ย่อมทำให้แอพพลิเคชั่นไม่เสถียรและจำเป็นต้องมีขั้นตอนการทำให้เสถียรโดยเฉพาะ เราได้ลอง: การสร้างใหม่ในต้นแบบที่มีการผสานเป็นระยะจากต้นแบบ (MB) ถึงคุณลักษณะสาขา (FB) (ความผิดพลาดของฉัน) ผลลัพธ์:มีสาขาไม่แน่นอนจำนวนมาก สิ่งที่เราได้รับคำแนะนำ: ลิงก์ไปยังบทความ (pdf) สร้างสาขาเพิ่มเติมสำหรับการเปลี่ยนโครงสร้าง (RB) เป็นระยะให้ตรงกันกับ MB ผ่านการผสานจาก MB ไปยัง RB หลังจาก RB มีความเสถียรเราจะเปลี่ยนต้นแบบเป็น RB และสร้างสาขาใหม่สำหรับการปรับโครงสร้างเพิ่มเติม นี่คือแผน แต่ที่นี่ฉันคาดหวังว่านรกที่แท้จริงของการรวม MB กับ RB หลังจากรวม FB เข้ากับ MB ข้อได้เปรียบหลัก: ผู้เชี่ยวชาญที่มีเสถียรภาพส่วนใหญ่เวลา มีทางเลือกใดที่ดีกว่าในการใช้ผลิตภัณฑ์นี้?

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

3
แทนที่รหัสประเภทด้วยคลาส (จาก Refactoring [Fowler])
กลยุทธ์นี้เกี่ยวข้องกับการแทนที่สิ่งนี้: public class Politician { public const int Infidelity = 0; public const int Embezzlement = 1; public const int FlipFlopping = 2; public const int Murder = 3; public const int BabyKissing = 4; public int MostNotableGrievance { get; set; } } ด้วย: public class Politician { public MostNotableGrievance …
9 c#  refactoring 

6
โซลูชันซอฟต์แวร์จากปี 2000 ฉันควรพยายามแก้ไขหรือสร้างสิ่งใหม่ทั้งหมดหรือไม่
ฉันถูกส่งออกไปเพื่อหารือเกี่ยวกับระบบที่ บริษัท หนึ่งกำลังใช้งานอยู่และสิ่งที่ควรทำกับ บริษัท บริษัท ผู้ผลิตกล่องแสดงต่างๆ ระบบนี้พัฒนาขึ้นเพื่อติดตามลูกค้าคำสั่งซื้อและราคา มีหลายสิ่งเกิดขึ้นตั้งแต่สร้างระบบและระบบอยู่ในขณะนี้ตามที่ผู้จัดการอธิบายว่า " ล็อค " และ " มีปัญหา " ซึ่งฉันแปลว่า "ไม่ใช่ไดนามิก" และ "ไม่เสถียร" ข้อมูลบางอย่างเกี่ยวกับระบบ มันได้รับการพัฒนาประมาณปี 2000 ระบบขนาดเล็กพอสมควรผู้ใช้ 2-5 คน 6 รูปแบบ ~ 8 ตารางพร้อมปริมาณข้อมูลโดยเฉลี่ย สร้างขึ้นใน Visual Basic รุ่นแรกสร้างด้วยการลากและวาง อินเตอร์เฟสนั้นเป็นเพียงหน้าต่างที่มีเมนูและบางรูปแบบ ใช้ฐานข้อมูล MSSQL (เซิร์ฟเวอร์ SQL2005) เพื่อเก็บข้อมูลและโปรแกรมควบคุม ODBC เพื่อทำการสืบค้นข้อมูลถูกย้ายจาก excel ก่อนระบบนี้และก่อนที่ excel จะถูกจัดการคำนวณและเขียนด้วยมือและกระดาษ ผู้ใช้ทำงานในสภาพแวดล้อม Microsoft XP (และสูงกว่า) …

7
ฉันควรจะใส่ใจไหมถ้าอัตราส่วน LOC ต่อวันของฉันสูงเกินไป [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว ขณะนี้ฉันกำลังทำงานในโครงการอินดี้ดังนั้นฉันจึงไม่ได้มีความหรูหราตลอดการทดสอบของมนุษย์หรือการตรวจสอบรหัสภายนอก - อย่างไรก็ตามฉันไม่เห็นข้อผิดพลาดที่ยากในรหัสปัจจุบันของฉัน (ฉันแก้ไขได้ตามที่เห็น และส่วนใหญ่พวกเขาเพียงแค่ชื่อฟิลด์ผิดและสิ่งที่คุณแก้ไขในหนึ่งหรือสองนาที) และฉันทดสอบหลังจากใช้งานคุณลักษณะใด ๆ ก่อนที่จะผลักดันมัน เมื่อเร็ว ๆ นี้หมายเลข LOC ของฉันอยู่ที่ประมาณ 400 ต่อวัน (สำหรับบันทึกเป็น C #) และฉันไม่เพียง แต่ใช้ระบบใหม่ แต่ยังเขียนสิ่งที่ฉันเขียนไปแล้วและแก้ไขข้อบกพร่องบางอย่าง ฉันควรจะใส่ใจไหม มันเป็นสัญญาณที่ฉันต้องหยุดและตรวจสอบรหัสทั้งหมดที่ฉันได้เขียนถึงวันนี้และ refactor มันได้หรือไม่
9 c#  refactoring 

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

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