Rekan kerja saya membuat tabel SQL 96 kolom

Di sini kita di tahun 2010, insinyur perangkat lunak dengan 4 atau 5 tahun atau pengalaman, masih merancang tabel dengan 96 kolom fracking.

Saya katakan padanya itu akan menjadi mimpi buruk.
Saya menunjukkan kepadanya bahwa kita harus menggunakan ordinals untuk antarmuka MySQL dengan C #.
Saya menjelaskan bahwa tabel dengan kolom lebih banyak daripada baris adalah bau yang sangat besar.

Namun, saya mendapatkan "Ini akan menjadi lebih sederhana dengan cara ini".

Apa yang harus saya lakukan?

EDIT *

Tabel ini berisi data dari sensor.
Kami memiliki sensor 1 dengan
Dynamic_D1X
Dynamic_D1Y
[...]

Dynamic_D6X
Dynamic_D6Y
[...]

EDIT2 *

Ya, akhirnya saya meninggalkan pekerjaan itu. Ini adalah tanda ketika programmer lain menjadi gelap selama berbulan-bulan pada saat itu, itu adalah tanda lain ketika manajemen tidak menyadari bahwa ini adalah masalah.

Mungkin dia melakukan itu untuk alasan yang bagus, seperti pertunjukan atau ROI? .

Hal terbaik untuk dilakukan, adalah mengajukan pertanyaan kepadanya. Dengan jumlah tertentu "mengapa" Anda tentu akan membuatnya mengerti bahwa ia mungkin salah dengan sendirinya (jika memang benar).

Saya punya satu kasus sendiri yang tidak terkait dengan kinerja tetapi pengembalian investasi (ROI). Saya memiliki tabel yang berisi objek yang memiliki nilai spesifik untuk setiap jam dalam seminggu (168 jam dalam seminggu). Kami memiliki pilihan untuk membuat tabel ObjectHour yang akan berisi nilai, tetapi juga kunci untuk Object dan jumlah hari jumlah jam. Tetapi kami juga memiliki kesempatan untuk menempatkan nilai-nilai 168 tepat di barisan. Mungkin seperti yang dilakukan rekanmu.

Pengembang memperkirakan kedua solusi. Solusi sederhana (168 kolom) jauh lebih murah untuk dilakukan daripada mitra yang dirancang dengan baik. Untuk hasil yang sama persis bagi pelanggan.

Kami memutuskan untuk mencari solusi sederhana / termurah untuk memfokuskan upaya kami pada hal-hal yang lebih penting seperti keamanan.

Kami akan memiliki banyak peluang untuk meningkatkannya di masa depan. Waktu untuk memasarkan adalah prioritas bagi kami pada saat itu.

Sayangnya pengembang rata-rata Anda masih menganggap database relasional sebagai file flat besar. Satu-satunya cara mereka akan menjadi lebih baik adalah jika seseorang mengambil alih dan memimpin dengan memberi contoh. Baru-baru ini saya mempelopori desain ulang utama dari skema penting dalam database kami dan mengikuti praktik relasional yang umum. Tiba-tiba prosedur tersimpan kami menjadi lebih elegan dan semua indeks yang tepat tampaknya jatuh ke tempatnya seperti mereka dilahirkan untuk itu. Pengembang yang didorong oleh ego tidak akan pernah percaya Anda tanpa bukti.

Sesuatu yang serupa telah dibahas sebelumnya di StackOverflow .

Secara umum, memiliki banyak kolom di atas meja belum tentu berarti Anda melakukan sesuatu yang salah, tapi pasti harus menaikkan beberapa bendera merah sehingga Anda melihat dekat pada desain. Terkadang meja besar adalah pilihan yang tepat, tetapi dalam banyak kasus, alternatif lain lebih masuk akal. Misalnya, satu opsi adalah untuk membagi penyimpanan menjadi dua tabel: satu tabel yang mengidentifikasi entitas Anda dan tabel lain yang secara efektif merupakan penyimpan kunci / nilai atribut yang menggambarkan entitas tersebut (sehingga Anda dapat memiliki paling banyak 96 barisuntuk setiap entitas). Desain lain juga dimungkinkan. Berbicara dengan rekan tim Anda dan mencari tahu solusi mana yang lebih baik tergantung pada normalisasi data, keterbacaan kode & pemeliharaan (memasukkan pernyataan dengan 96 atribut untuk diisi?), Implikasi kinerja, seberapa sering atribut baru (kolom) dapat ditambahkan atau diubah, seberapa jarang datanya adalah (berapa banyak dari 96 kolom yang akan diisi dan berapa banyak yang tetap NULL?), dan implikasi pada pelaporan. Setiap pengembang harus dapat membenarkan keputusan desain mereka dan menunjukkan bahwa biaya / manfaat saling menguntungkan (dan ya, setiap keputusan desain adalah pertukaran) menguntungkan mereka. Tanggung jawab Anda bukan untuk mengeluh atau mengkritik, tetapi untuk mengusulkan alternatif dan memastikan mereka memikirkan masalah-masalah ini.

Apakah dinormalisasi dengan 96 kolom? Apakah memenuhi NF 1, 2, 3 dll?

Mungkin Anda memiliki 96 atribut terpisah untuk entitas.

Kalau tidak, buat dia membaca Joe Celko di Simple Talk

Itu sepenuhnya tergantung.

Desain DB yang dinormalisasi / tidak normal memiliki kelebihan dan kekurangan masing-masing.

Desain DB pertama saya adalah hal kecantikan yang dinormalisasi. Itu fleksibel dan dapat diperpanjang. Itu juga PITA yang luar biasa bagi siapa pun kecuali saya untuk berurusan dengan pada tingkat kode, dan itu adalah PITA ringan bagi saya.

Usaha saya berikutnya adalah struktur datar, dan (a) jauh lebih cepat dan (b) lebih mudah untuk dikodekan. Dan itu tidak akan menjadi tugas besar untuk dinormalkan lagi nanti.

Jadi itu mungkin bau tetapi beberapa desain DB lainnya akan memiliki susunan aroma yang menyenangkan.

Buat dia membaca artikel ini tentang utang teknis . Jika dia masih memutuskan untuk mempertahankannya, maka setidaknya Anda telah memberikan pendapat yang membangun.

Melihat posting (diedit), jelas bahwa ini adalah tabel dengan denormalized yang buruk. Apa yang harus kamu lakukan Seperti yang saya lihat, Anda punya beberapa opsi:

1. Berteriaklah pada rekan kerja Anda untuk belajar bagaimana melakukan pekerjaannya. Tidak mungkin produktif tetapi mungkin akan meyakinkan rekan kerja lain untuk tidak mengacaukan Anda. Reputasi sebagai maniak yang berteriak bisa berguna (jangan tanya saya bagaimana saya tahu).
2. Berteriaklah pada bos bahwa rekan kerjanya itu idiot. Prediksi bencana, kemudian secara aktif bekerja untuk menyabot proyek. Salahkan semuanya pada desain database yang dihasilkan oleh rekan kerja yang tidak kompeten. Dapat mengarah langsung ke ...
3. Berhenti. Terbaik jika itu idemu, tetapi # 2 dapat menyebabkan pengunduran diri secara tidak sukarela. Cobalah untuk tidak mengikis lutut di atas aspal / beton / kerikil jika dilempar dari jendela oleh bos dan / atau rekan kerja yang marah. (Perhatikan bahwa penelitian sebelumnya adalah PENTING di sini. Peluang Anda untuk bertahan hidup berkurang secara nyata jika bos kantor berada di atas lantai dasar dan Anda menemukan diri Anda didorong keluar secara fisik ke luar jendela. Rencanakan ke depan !! )
4. Minumlah banyak - atau, pindah ke California dan menyala (dengan asumsi prop. 19 (atau apa pun) berlalu). Tidak ada yang seperti beberapa tembakan dan doobie untuk meningkatkan pandangan seseorang pada rekan kerja seseorang (atau begitulah yang saya dengar). (Pengumuman layanan publik: KIDS! Orang-orang ini profesional! JANGAN coba-coba di rumah!)

Bagikan dan nikmati.

Saya akan pergi mengambil risiko di sini dan menganggap dia akan memotong dan menempelkan banyak kode untuk bekerja dengan tabel "Baru" ini.

Jika demikian, Anda mungkin tidak akan dikenakan hutang teknis tambahan. Dia baru saja membagi bagiannya dari hutang teknis dan mungkin sedang dalam perjalanan menuju semacam penyatuan besar hal.

Jika dia punya metodologi yang sudah teruji dan benar yang membutuhkan 96 kolom, pertimbangkan manfaat sebenarnya dari melakukannya dengan cara yang berbeda dalam kasus khusus ini. Jika tidak ada, maka berikan dia keuntungan dari keraguan, tetapi ingatkan dia bahwa lain kali Anda ingin berada di tahap perencanaan saat berikutnya dia membuat apa yang kita semua anggap sebagai langkah yang cukup bodoh.

Tergantung sepenuhnya pada kasus penggunaan aplikasi yang akan mengakses skema, potongan data apa yang diperlukan pada suatu waktu. Dalam beberapa cara itu mungkin membenarkan desain tabel.

Saya akan mengirimnya ke zaman batu dan memaksanya untuk menggunakan file atau setidaknya mengajarinya cara menggunakan gumpalan.

Sungguh, 96 kolom ... Itu tidak mungkin benar. Mungkin ORM akan membantu. (Kecuali jika Anda membutuhkan kinerja tetapi Anda kemudian dapat memiliki seseorang yang memahami DB lebih baik untuk menanganinya)

Saya akan downvoted semua ke neraka untuk ini, tapi inilah mengapa saya memisahkan tanggung jawab pemodelan data dan rekayasa perangkat lunak di toko saya. Pemrogram jarang berpikir dalam bentuk set dan bukannya fokus pada penggunaan data (daripada mempertahankan bentuk normal ke-3, pengindeksan, atau masalah kinerja DB lainnya). Kita sebagai programmer juga cenderung lebih tidak setuju pada keputusan arsitektur DB daripada yang seharusnya, berdasarkan pada pengalaman kami dalam pemodelan data murni / masalah arsitektur. IMHO, saya suka bahwa saya memiliki arsitek data dan pemodel yang mengambil persyaratan, membangun tabel / procs / dll, dan membiarkan berurusan dengan output sampai kepada saya.

Tanpa mengetahui alasan sebenarnya untuk desain ini (saya telah bekerja pada sensor cuaca yang memiliki lebih dari 96 output numerik yang berbeda = sejumlah besar kolom tabel) ... sepertinya ini seperti buang air kecil kesayangan.