การสร้างและลบตารางอย่างต่อเนื่องเป็นสัญญาณของข้อบกพร่องทางสถาปัตยกรรมหรือไม่?

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

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

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

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

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

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

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

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

DBA จะช่วยได้เพียงให้แน่ใจว่าคุณได้รับ DBA ที่เข้าใจการพัฒนาและการพัฒนาที่คล่องตัว ทีมพัฒนาของคุณต้องได้รับการฝึกฝนอีกครั้งไม่ต้องติดคุก

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

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

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

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

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

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

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

นักพัฒนาส่วนใหญ่ไม่ปรับฐานข้อมูลให้เป็นปกติเนื่องจากข้อ จำกัด ด้านเวลาความเกียจคร้านความไร้ความสามารถหรือความซับซ้อนของแบบสอบถาม การปรับสภาพใหม่ต้องมีการถ่ายโอนข้อมูลที่มีอยู่การปรับเปลี่ยน DAO's ฯลฯ ฯลฯ ซึ่งสร้างปัจจัยความเสี่ยง

เพื่อตอบคำถามของคุณไม่ใช่นั่นไม่ใช่เรื่องปกติในกระบวนการเปรียว

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

ต้องบอกว่าฉันยังไม่ได้ทำงานกับนักพัฒนาที่สมัครสมาชิกทฤษฎี Agile และวิธีการและยังคิดว่าการสร้างและการลบตารางในสคีมาเป็นสิ่งจำเป็นด้วยเหตุผลใดก็ตาม Agile ไม่ได้หมายถึง slap-dash หรือ bolt-on ถ้าคุณได้รับเรื่องที่ต้องเพิ่มเขตข้อมูลใหม่ที่เป็นของระเบียนเฉพาะคุณเพิ่มเขตข้อมูลลงในตาราง ถ้าการเปลี่ยนแปลงนั้นทำลายบางสิ่งคุณคิดว่าทำไมและทำการเปลี่ยนแปลงอื่น ๆ ตามที่จำเป็น (ฉันสามารถนึกถึงสิ่งเล็ก ๆ น้อย ๆ ที่จะทำลายโดยการเพิ่มคอลัมน์ในฐานข้อมูลที่ถูกสอบถามถ้ามันเป็นการเปลี่ยนแปลงที่คุณทำแบบนี้ มีปัญหาใหญ่กว่า) การรีฟอร์เรชั่น จำกัด ตามรหัส การเปลี่ยนสคีมามักจะเป็นกระบวนการที่เกี่ยวข้องมากกว่าการเปลี่ยนรหัสและดังนั้นเมื่อการเปลี่ยนแปลงสคีมาต้องเกิดขึ้นพวกเขามักจะทำด้วยความระมัดระวังมากขึ้น และอย่างน้อยก็ให้ความสนใจกับความรู้เกี่ยวกับทิศทางในอนาคตของโครงการ ต้องปรับโครงสร้างฐานข้อมูลบางส่วนหรือทั้งหมดบ่งชี้ถึงความล้มเหลวพื้นฐานของการออกแบบ การมีความคล่องตัวไม่ได้หมายความว่าไม่มี "แผนแม่บท" ของสถาปัตยกรรมพื้นฐานและกฎการออกแบบที่ต้องปฏิบัติตามในขณะที่สร้างโปรแกรมและโครงสร้างข้อมูลแบบอินทรีย์

ตอนนี้มีหลายกรณีใน Agile ที่สิ่งที่คุณ "รู้" ตอนนี้จะขัดแย้งกับสิ่งที่คุณจะเรียนรู้ในภายหลัง สมมติว่าคุณมีข้อกำหนดที่ระบบของคุณต้องมีที่อยู่สำหรับทุกคน เนื่องจากนี่เป็นความสัมพันธ์แบบ 1: 1 และข้อมูลจะต้องการในกรณีส่วนใหญ่คุณเพียงเพิ่มเขตข้อมูลที่อยู่ลงในตารางบุคคล หนึ่งสัปดาห์ต่อมาคุณจะได้รับข้อกำหนดว่าบุคคลสามารถมีที่อยู่ได้มากกว่าหนึ่งแห่ง ตอนนี้มันเป็นความสัมพันธ์แบบ 1: N และในการสร้างแบบจำลองอย่างถูกต้องคุณจะต้องยกเลิกการเปลี่ยนแปลงก่อนหน้าโดยแยกฟิลด์ออกเป็นตารางที่อยู่ใหม่ นี่ไม่ใช่กิจวัตรโดยเฉพาะในหมู่นักพัฒนาอาวุโส นักพัฒนาที่มีประสบการณ์จะเห็นว่าบุคคลนั้นมีที่อยู่ให้พิจารณาสิ่งเหล่านี้เป็นแนวคิดแยกจากกันและสร้างตารางบุคคลและตารางที่อยู่เชื่อมโยงบุคคลกับที่อยู่ด้วยการอ้างอิง FK ไปยัง AddressID สคีมาเช่นนี้ง่ายต่อการเปลี่ยนแปลงหากธรรมชาติของความสัมพันธ์เปลี่ยนไป โดยไม่ต้องสร้างหรือลบตารางข้อมูล "กว้าง" ทั้งหมดความสัมพันธ์ระหว่างบุคคลและที่อยู่สามารถปรับเปลี่ยนได้อย่างง่ายดายตั้งแต่ 1: 1 ถึง 1: N ถึง N: N

ไม่ได้เน้นไปที่การออกแบบล่วงหน้ามากนักเมื่อทำงานภายใต้ Agile ดังนั้นฉันไม่เห็นว่านี่เป็นปัญหาใหญ่แน่นอนสำหรับการเปิดตัวครั้งแรก

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

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

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

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

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

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

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

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