Perusahaan saya memiliki model pengembangan seperti air terjun, di mana pengguna bisnis dan analis bisnis kami akan menentukan persyaratan untuk proyek. Pada salah satu proyek "besar" kami, kami mendapat setumpuk persyaratan, dan saya perhatikan sejumlah persyaratan berisi detail implementasi , khususnya informasi yang berkaitan dengan skema basis data kami yang digunakan oleh sistem akuntansi kami.
Saya berkomentar kepada pengguna bisnis bahwa implementasi adalah domain saya , seharusnya tidak tercantum dalam persyaratan. Mereka tidak mau mengubah persyaratan mereka karena, bagaimanapun, mereka adalah BISNIS, dan hanya masuk akal bagi akuntan untuk merancang perangkat lunak akuntansi. Sebagai pengembang rendahan yang terlalu jauh dalam jajak pendapat totem, saya dibayar untuk melakukan alih - alih berpikir . Sebanyak yang saya perjuangkan, saya tidak bisa membujuk mereka untuk menulis ulang persyaratan - ada terlalu banyak dokumen dan birokrasi di sekitar perubahan yang terlalu merepotkan.
Jadi, saya memberi mereka apa yang mereka minta. Paling tidak, ini agak berfungsi , tetapi database dirancang dengan aneh:
Banyak normalisasi yang tidak perlu. Catatan tunggal yang berisi 5 atau 10 bidang dibagi menjadi 3 atau 4 tabel. Saya bisa mengatasinya, tetapi secara pribadi saya ingin semua bidang 1: 1 ditarik ke dalam satu tabel.
Banyak denasionalisasi yang tidak pantas. Kami memiliki tabel yang menyimpan data faktur yang menyimpan lebih dari data faktur. Kami menyimpan sejumlah flag lain-lain dalam tabel InvoiceData, bahkan jika flag tersebut tidak terkait secara logis dengan tabel InvoiceData, sehingga setiap flag memiliki nilai kunci Primary yang di-hardcoded dan semua bidang lainnya dibatalkan dalam tabel InvoiceData. Karena bendera direpresentasikan sebagai catatan dalam tabel, saya menyarankan menarik bendera ke tabelnya sendiri.
Banyak lagi denasionalisasi yang tidak pantas. Flag aplikasi-lebar tertentu disimpan sebagai kolom dalam tabel yang tidak pantas, sehingga mengubah flag aplikasi memerlukan pembaruan setiap catatan dalam tabel.
Kunci primer berisi metadata, sehingga jika kunci utama varchar diakhiri dengan "D", kami menghitung faktur menggunakan satu set nilai, jika tidak kami menghitungnya dengan set lain. Akan lebih masuk akal untuk menarik metadata ini ke dalam kolom terpisah, atau menarik himpunan nilai untuk dihitung ke dalam tabel lain.
Kunci asing sering kali mengarah ke lebih dari satu tabel, sehingga kunci asing yang diakhiri dengan "M" dapat ditautkan ke tabel akun hipotek kami, sedangkan kunci asing yang diakhiri dengan "A" mungkin menautkan ke tabel akun otomatis kami. Akan lebih mudah untuk membagi data menjadi dua tabel, MortageData dan AutoInsuranceData.
Semua saran saya ditembak jatuh dengan banyak ratapan dan kertakan gigi. Aplikasi ini berfungsi seperti yang dirancang, dan sementara itu adalah bola lumpur yang besar, semua peretasan jahat, kasing khusus, dan aturan bisnis aneh didokumentasikan secara sarkastik dan lucu dalam kode sumber.