Refactoring atau pemutakhiran basis data untuk menangani fitur baru

Beberapa respons terhadap pertanyaan skema database , menyarankan tabel tambahan untuk menormalkan database untuk fitur yang bukan bagian dari persyaratan saat ini (Tabel UserDepartment untuk memungkinkan hubungan banyak-ke-banyak antara karyawan / pengguna dan berbagai departemen yang mungkin mereka miliki. milik.).

Bukan menentang normalisasi. Sepertinya ketika datang ke desain database, ada dorongan kuat untuk memasukkan fitur yang mereka 'yakin' seseorang akan inginkan di masa depan. Apakah begitu sulit untuk menambahkan tabel / bidang ke database untuk mengakomodasi fitur yang ada kecenderungan untuk over-engineer? Bukankah mereka akan di-refactored atau ditingkatkan seperti aplikasi lainnya jika diperlukan? Mengulangi hal tidak pernah menyenangkan, tetapi memindahkan data dari satu tabel ke yang baru dapat dilakukan. Hanya tidak yakin di mana garis pemikiran ini akan berakhir.

Sunting: Ada begitu banyak keengganan untuk ini, saya bertanya-tanya berapa banyak proyek akhirnya tidak menambahkan fitur yang membutuhkan perubahan database drastis atau pendekatan non-normalisasi diambil seperti menambahkan bidang DepartmentID2 alih-alih tabel baru. Kebutuhan akan banyak departemen untuk seorang karyawan adalah masalah domain yang umum. Saya hanya belum melihat banyak skema database yang berserakan dengan banyak-ke-banyak hubungan.

Ada seluruh buku yang ditulis tentang refactoring basis data. Sama seperti dengan kode refactoring, ada cara standar untuk melakukan refactoring database. Satu-satunya perbedaan adalah bahwa ketika melakukan refactoring kode, Anda tidak harus mempertimbangkan keadaan objek / kode, sedangkan dalam database Anda harus mempertimbangkan data, karena kehilangan data tidak baik untuk pengguna (atau bagi siapa pun, sebenarnya ).

Anda dapat membaca lebih lanjut tentang refactoring basis data di sini .

Kode refactoring mudah - Anda cukup mengubah kode dan menjalankan tes regresi Anda.

Database refactoring sulit - Anda harus memindahkan (kemungkinan besar jumlah) data di sekitar, pastikan tidak ada yang dijatuhkan, pastikan kendala dipertahankan dalam skema baru. Dan, jika Anda memiliki persyaratan audit pada data, Anda harus dapat menjelaskan mengapa itu diatur secara berbeda dan dapat mencocokkan data pra-refoctor dengan data pasca-refactor. Juga, tidak ada cadangan lama Anda yang akan cocok dengan skema baru, yang merupakan risiko lain.

Barang yang mengerikan.

Ada garis tipis antara menghabiskan banyak waktu over-engineering dan menginvestasikan sedikit waktu Anda untuk menambahkan fitur yang cukup untuk menghemat banyak waktu di masa depan.

Saya pikir teorinya adalah bahwa jika Anda menyertakan tabel tautan untuk mendukung hubungan banyak ke banyak antara 2 tabel, maka bahkan jika benar-benar hanya banyak hubungan yang ada dalam data, semua orang akan menulis SQL sedemikian rupa sehingga jika pernah ada banyak ke banyak didukung semuanya akan "hanya berfungsi".

Dalam prakteknya saya tidak biasa menemukan bahwa ini benar, tetapi saya kira SQL lebih dekat dengan apa yang diperlukan untuk mendukung banyak ke banyak daripada yang seharusnya.

Tetapi untuk mendapatkan pertanyaan Anda secara khusus, sebenarnya ada cukup banyak rasa sakit untuk mengubah hubungan dari 1 ke banyak ke banyak ke banyak. Alasannya adalah bahwa SQL tidak dirancang dengan jenis tujuan enkapsulasi yang sama dengan objek, dan sebagian besar kueri menggunakan lebih banyak tabel pada lapisan database daripada orang akan merasa nyaman memiliki objek di lapisan bisnis memiliki visibilitas.

Oleh karena itu perubahan ke banyak ke banyak hubungan akan berdampak pada setiap kueri yang melibatkan 2 tabel asli, seringkali efek cascading yang jauh lebih luas daripada yang akan terjadi pada lapisan bisnis. Jadi orang berusaha keras untuk mencegah hal ini terjadi.

IMHO ini tidak diperlukan jika kita memiliki bahasa yang lebih baik daripada SQL untuk menentukan aljabar relasional. Jika layak untuk membangun sepotong demi sepotong permintaan SQL objek yang tidak perlu visibilitas ke setiap tabel dalam permintaan ini tidak akan terjadi. Hal-hal seperti LINQ (ke SQL atau Entitas) berusaha untuk menyelesaikan ini, tetapi ini adalah solusi yang sangat kompleks dan sulit untuk dioptimalkan (dan saya pernah ke grup pengguna DBA di mana LINQ disebutkan dan keluhan kolektif meningkat setiap saat). Saya memimpikan bahasa basis data yang secara universal didukung dengan fungsi aljabar relasional kelas satu ...

Sementara itu, ya, Anda dapat refactor dari 1-ke-banyak ke banyak-ke-banyak, tetapi bisa banyak pekerjaan.

Saya biasanya menjelaskan dengan cara ini ke PHB - kode adalah dinding dan atap, database adalah fondasi.

Memindahkan dinding dan mengganti atap bisa dilakukan. Mengubah fondasi di sekitar membutuhkan banyak penggalian dan pembangunan kembali dinding dan atap.

Apa yang dikatakan oleh pengembang yang tidak berpengalaman (dan profesor perguruan tinggi) adalah "over engineering" adalah apa yang oleh pengembang berpengalaman disebut "proofing di masa depan". Terlepas dari apa yang menurut spesifikasi Anda tahu apa yang mungkin akan berubah selama ALM atau di mana masalah kinerja akan terjadi sehingga Anda ingin mendapatkan struktur tabel yang tepat untuk memulai.

Meluncurkan skrip pembaruan ke server pelanggan adalah proyek non-sepele dan masing-masing DBA pelanggan siap membantu Anda untuk memeriksa semuanya. Beberapa kolom dan tabel tambahan tidak terlalu buruk.

Aturan umum adalah jika hubungan adalah salah satu untuk satu tapi mungkin di masa depan akan banyak ke banyak kemudian membuatnya menjadi banyak ke banyak.

Karyawan / departemen adalah contoh klasik. Dalam sebagian besar perusahaan kecil ini secara efektif hubungan satu ke banyak sebagian besar waktu . Namun hampir selalu ada situasi di mana ia menjadi banyak ke banyak - salah satu insinyur Anda naik ke manajemen, tetapi, masih bertanggung jawab untuk mendukung produk yang ia kembangkan saat ia masih di bidang teknik, atau, salah satu tenaga penjualan Anda pindah ke pengembangan produk, tetapi, karena dia memiliki hubungan dekat dengan pelanggan penting, dia masih memimpin salesman untuk pelanggan itu.

Tidak perlu biaya lebih banyak jika satu ke banyak diimplementasikan sebagai banyak ke banyak - tetapi refactoring database dan aplikasi untuk mendukung banyak ke banyak mahal dan penuh dengan kesulitan.

Ada dua cara untuk melihat desain perangkat lunak (dan mungkin banyak hal lainnya) - Pandangan taktis atau pandangan strategis. Masing-masing memiliki kelebihan dan kekurangannya sendiri.

Bahkan dengan modifikasi perangkat lunak OO masih menyusahkan, tidak hanya bagian pengkodean yang sulit, tetapi proses mempromosikan perubahan produksi dalam lingkungan keluhan (mengingat teknologi saat ini.) Tidak nyata untuk sistem besar yang seharusnya bekerja 24/7.

Saya mengikuti prinsip saya yang mengatakan: " Jika mungkin, rancang artefak perangkat lunak bersama secara strategis " - Ini mungkin terdengar seperti bertentangan dengan prinsip YAGNI dalam beberapa cara, bagaimanapun, ini adalah pendapat saya. Pendekatan ini menjamin lebih sedikit bekerja kembali pada biaya kompleksitas dan sumber daya.

Dalam kasus Anda, kegiatan yang diperlukan untuk menambahkan tabel persimpangan baru akan meliputi: desain, persetujuan desain, mengubah skema, menulis ulang beberapa metode untuk CRUD untuk 3 tabel (dengan pengecualian beberapa bacaan), membangun indeks, membuat GUI untuk CRUD untuk tabel baru, untuk memungkinkan pengguna untuk memilih PKs dalam pembuatan, memperbarui tabel baru, dll. Oh, dan omong-omong jangan lupa pengujian unit, pengujian penerimaan pengguna, pengujian sistem dan promosi produksi.

Jika ini tidak cukup, mimpi buruk yang sebenarnya datang dari kehilangan informasi. Jika Anda tidak memiliki tabel persimpangan untuk memulai dan Anda memutuskan untuk menangkap tanggal di mana hubungan / pemisahan antara karyawan dan departemen terjadi, Anda tidak akan dapat secara otomatis mengisi tanggal pada tabel persimpangan. Anda harus memasukkannya secara manual (jika Anda memiliki data).

Jadi, lebih baik meramalkan ini sejak awal.

Seperti yang Matthew katakan di atas, refactoring / mengubah database sering kali lebih terlibat dibandingkan dengan perangkat lunak karena pengelolaan data juga perlu dipertimbangkan. Ada beberapa teknik yang dapat membantu misalnya memastikan bahwa Anda memiliki rangkaian pengujian unit basis data yang tepat, memisahkan aplikasi klien dari skema dasar Anda dengan menggunakan 'DB API' - sprocs / tampilan dll.