เพื่อนร่วมงานของฉันสร้างตาราง SQL 96 คอลัมน์

ที่นี่เราอยู่ในปี 2010 วิศวกรซอฟต์แวร์ที่มี 4 หรือ 5 ปีหรือประสบการณ์ยังคงออกแบบตารางที่มีคอลัมน์ 96 fracking

ฉันบอกเขาว่ามันจะเป็นฝันร้าย
ฉันแสดงให้เขาเห็นว่าเราต้องใช้กฎเพื่อเชื่อมต่อ MySQL กับ C #
ฉันอธิบายว่าตารางที่มีคอลัมน์มากกว่าแถวมีกลิ่นมาก

ถึงกระนั้นฉันได้รับ "มันจะง่ายขึ้นด้วยวิธีนี้"

ฉันควรทำอย่างไร?

แก้ไข *

ตารางนี้มีข้อมูลจากเซ็นเซอร์
เรามีเซ็นเซอร์ 1 พร้อมด้วย
Dynamic_D1X
Dynamic_D1Y
[... ]

Dynamic_D6X
Dynamic_D6Y
[... ]

แก้ไข 2 *

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

บางทีเขาทำอย่างนั้นด้วยเหตุผลที่ดีเช่นการแสดงหรือ ROI .

สิ่งที่ดีที่สุดที่จะทำคือถามคำถามเขา ด้วยจำนวน "ทำไม" คุณจะทำให้เขาเข้าใจอย่างแน่นอนว่าเขาอาจจะผิดด้วยตัวเอง (ถ้าเขาเป็นจริง)

ฉันมีกรณีหนึ่งที่ไม่เกี่ยวข้องกับการแสดง แต่ให้ผลตอบแทนการลงทุน (ROI) ฉันมีตารางที่มีวัตถุที่มีค่าเฉพาะสำหรับแต่ละชั่วโมงของสัปดาห์ (168 ชั่วโมงต่อสัปดาห์) เรามีทางเลือกในการสร้างตาราง ObjectHour ที่จะมีค่า แต่ยังเป็นกุญแจสำคัญใน Object และหมายเลขวันของจำนวนชั่วโมง แต่เราก็มีโอกาสที่จะใส่ค่า 168 ค่าลงในแถว อาจชอบสิ่งที่คุณทำ coleague

นักพัฒนาประเมินโซลูชั่นทั้งสอง วิธีแก้ปัญหาอย่างง่าย (168 คอลัมน์) นั้นถูกกว่าการทำมากกว่าการออกแบบที่ดี เพื่อผลลัพธ์ที่แน่นอนเหมือนกันสำหรับลูกค้า

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

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

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

สิ่งที่คล้ายกันถูกกล่าวถึงก่อนหน้านี้ในStackOverflow

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

มันเป็นมาตรฐานกับ 96 คอลัมน์? มันเป็นไปตามที่ 1, 2, 3 ฯลฯ NF หรือไม่

อาจเป็นได้ว่าคุณมี 96 แอ็ตทริบิวต์แยกต่างหากสำหรับในเอนทิตี

มิฉะนั้นให้เขาอ่านJoe Celko ใน Simple Talk

มันสมบูรณ์ขึ้นอยู่กับ

การปรับฐานข้อมูลให้เป็นมาตรฐาน / ผิดปกติทั้งคู่มีข้อดีและข้อเสีย

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

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

ดังนั้นอาจเป็นกลิ่น แต่การออกแบบ DB อื่น ๆ จะมีกลิ่นที่น่าพึงพอใจ

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

เมื่อดูที่โพสต์ (แก้ไข) เห็นได้ชัดว่านี่เป็นตารางที่ไม่ถูกต้อง คุณควรทำอะไร? เท่าที่ฉันเห็นคุณมีตัวเลือกน้อย:

1. ตะโกนเรียกเพื่อนร่วมงานของคุณเพื่อเรียนรู้วิธีทำงานของเขา / เธอ / เธอ ไม่น่าจะมีประสิทธิผล แต่อาจโน้มน้าวให้เพื่อนร่วมงานคนอื่นไม่ยุ่งกับคุณ ชื่อเสียงในฐานะคนบ้าเสียงกรีดร้องนั้นมีประโยชน์ (อย่าถามฉันว่าฉันรู้ได้อย่างไร)
2. กรีดร้องใส่เจ้านายว่าเพื่อนร่วมงานเป็นคนงี่เง่า ทำนายภัยพิบัติจากนั้นก็ทำงานอย่างแข็งขันเพื่อก่อวินาศกรรมโครงการ ตำหนิทุกอย่างในการออกแบบฐานข้อมูลที่ผลิตโดยผู้ร่วมงานที่ไร้ความสามารถ อาจนำไปสู่ ​​...
3. เลิก. ดีที่สุดถ้าเป็นความคิดของคุณ แต่ # 2 อาจนำไปสู่การลาออกโดยไม่สมัครใจ พยายามอย่าถูหัวเข่าบนแอสฟัลต์ / คอนกรีต / กรวดหากพุ่งออกจากหน้าต่างโดยเจ้านายและ / หรือเพื่อนร่วมงานที่โกรธแค้น (โปรดทราบว่าการศึกษาก่อนหน้านี้มีความสำคัญที่นี่โอกาสในการอยู่รอดของคุณจะลดลงอย่างเห็นได้ชัดถ้าสำนักงานผู้บังคับบัญชาอยู่เหนือพื้นดินและคุณพบว่าตัวเองถูกผลักดันออกไปนอกหน้าต่าง วางแผนล่วงหน้า !! )
4. ดื่มหนัก - หรือย้ายไปแคลิฟอร์เนียแล้วสว่างขึ้น (สมมติว่าข้อเสนอที่ 19 (หรืออะไรก็ตาม) ผ่านไป ไม่มีอะไรที่เหมือนกับการถ่ายภาพสองสามนัดและผู้ฝึกหัดคนหนึ่งเพื่อปรับปรุงมุมมองของเพื่อนร่วมงาน (หรือที่ฉันเคยได้ยิน) (ประกาศการบริการสาธารณะ: KIDS! คนเหล่านี้เป็นมืออาชีพ! อย่าลองทำที่บ้าน!)

แบ่งปันและเพลิดเพลิน

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

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

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

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

ฉันจะส่งเขาไปยังยุคหินและบังคับให้เขาใช้ไฟล์หรืออย่างน้อยก็สอนเขาถึงวิธีการใช้ blobs

จริงๆ 96columns ... มันไม่ถูกต้องตลอดไป บางทีออมอาจจะช่วยได้ (ยกเว้นว่าคุณต้องการประสิทธิภาพ แต่คุณสามารถมีคนที่เข้าใจ DB ได้ดีกว่าในการจัดการ)

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

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