Kode Pertama vs. Database Pertama

Ketika saya mendesain dan membuat perangkat lunak tempat saya bekerja, saya biasanya merancang dan membuat tabel SQL back-end pertama dan kemudian beralih ke pemrograman yang sebenarnya. Proyek yang sedang saya kerjakan membuat saya bingung. Ini mungkin karena kurangnya persyaratan yang baik dan solid, tapi sayangnya hanya sedikit yang bisa saya lakukan mengenai hal itu kali ini. Ini semacam "hanya pergi mewujudkannya" situasi .. tapi aku ngelantur.

Saya berpikir untuk membalik alur kerja saya di atas kepala itu dan membuat UI dan kelas model data pertama dengan harapan bahwa bekerja keluar akan menjelaskan kepada saya seperti apa skema database saya nantinya. Apakah ini ide yang bagus? Saya gugup bahwa saya akan berakhir dengan UI dan masih tidak tahu bagaimana menyusun db.

Jika ada yang penasaran, saya menggunakan SQL Server sebagai backend dan MS Access sebagai aplikasi ujung depan. (Akses juga bukan pilihan saya ... jadi tolong jangan membencinya terlalu buruk.)

Apa yang datang lebih dulu, proses, atau data yang digunakan oleh proses itu? Saya tahu ini semacam pertanyaan "ayam atau telur", tetapi dalam hal perangkat lunak, saya percaya ini adalah prosesnya.

Misalnya, Anda dapat membangun model data Anda secara bertahap dengan menerapkan satu kasus penggunaan pada satu waktu hanya dengan ketekunan dalam memori (atau apa pun yang mudah diimplementasikan). Ketika Anda merasa telah menerapkan cukup kasus penggunaan untuk menguraikan entitas dasar, Anda dapat mengganti kegigihan dalam memori dengan database nyata, dan kemudian melanjutkan untuk memperbaiki skema saat Anda maju, satu kasus penggunaan pada satu waktu.

Ini mengeluarkan fokus dari database dan memindahkannya ke inti masalah: aturan bisnis. Jika Anda mulai dengan menerapkan aturan bisnis, pada akhirnya Anda akan menemukan (dengan proses yang sangat mirip dengan Seleksi Alam, omong-omong) data mana yang benar-benar dibutuhkan oleh bisnis. Jika Anda mulai dengan memodelkan database, tanpa umpan balik apakah data itu benar-benar diperlukan (atau dalam format itu, atau dalam tingkat normalisasi, dll ...), Anda akan berakhir dengan melakukan banyak penyesuaian terlambat di skema (yang mungkin memerlukan prosedur migrasi yang berat, jika bisnis sudah berjalan dengannya), atau Anda harus menerapkan "penyelesaian" dalam aturan bisnis untuk menebus model data yang tidak selaras.

TL; DR: Basis data tergantung pada bisnis - itu ditentukan oleh mereka. Anda tidak akan memerlukan data kecuali Anda memiliki proses yang beroperasi dengannya (laporan juga merupakan proses). Implementasikan proses terlebih dahulu, dan Anda akan menemukan data mana yang dibutuhkan. Modelkan dulu datanya, dan Anda mungkin bisa menghitung berapa banyak asumsi yang salah saat pertama kali memodelkannya.

Sedikit keluar dari topik tetapi sangat penting: alur kerja yang saya jelaskan sering digunakan bersama dengan praktik yang sangat penting seperti "Hal paling sederhana yang mungkin dapat bekerja", pengembangan yang digerakkan oleh tes, dan fokus pada memisahkan arsitektur Anda dari detail yang menghalangi jalan Anda (petunjuk: basis data). Tentang yang terakhir, ceramah ini merangkum gagasan dengan cukup baik.

Analisis akar penyebab menunjukkan masalah ini bukan salah satu metode, tetapi kurangnya spesifikasi. Tanpa satu itu tidak masalah apa yang Anda tulis pertama - Anda akan membuangnya.

Bantulah diri Anda sendiri dan lakukan beberapa analisis sistem dasar - identifikasi beberapa pengguna di berbagai tingkatan, buatlah kuesioner cepat & kotor, lalu matikan mesin Anda, ambil kopi dan kue / donat (atau apa pun yang meminyaki roda) lalu berjalan-jalan ke meja mereka, tanyakan kepada mereka apa yang mereka lakukan dan apa yang perlu mereka ketahui / catat untuk melakukan pekerjaan mereka bahkan jika itu tampak jelas - masih bertanya. Jangan khawatir tentang betapa pentingnya mereka, jika mereka terlalu sibuk maka buatlah pengaturan untuk kembali di lain waktu atau tinggalkan bersama mereka.

Setelah Anda memilikinya, Anda harus dapat mulai membangun apa pun yang menurut Anda akan memberikan hasil terbaik dan menunggu spesifikasi lainnya masuk.

Pengalaman saya adalah sebagai berikut:

• Dalam sebagian besar proyek yang saya kerjakan, kami merancang basis data terlebih dahulu.
• Sering kali data sudah ada di spreadsheet, basis data warisan, kertas, dll. Data itu akan memberi Anda petunjuk tentang tabel yang perlu Anda pegang.
• Sering kali suatu proses sudah digunakan, namun secara manual atau menggunakan beberapa, alat yang berbeda yang tidak otomatis, tidak saling beroperasi dan / atau tidak sesuai dengan standar.
• Setelah Anda memiliki model basis data semi-matang, Anda dapat mulai mendesain formulir prototipe, jendela dll., Yang membaca dan menulis ke basis data itu.
• Saat Anda melanjutkan, beberapa perubahan akan diperlukan untuk mengakomodasi hal-hal yang tidak dimaksudkan pada awalnya.

Ingat juga:

• Ini bukan lagi dunia satu-aplikasi <-> satu-basis data. Mungkin aplikasi Anda harus membaca atau menulis data dari lebih dari satu basis data atau solusi Anda terdiri dari lebih dari satu aplikasi menggunakan basis data yang sama.

Kesimpulan: Saya sarankan Anda untuk mendesain database terlebih dahulu.

Saya akan mengatakan Database Pertama karena saya memiliki banyak pengalaman dengan proyek-proyek besar dan Anda benar-benar membutuhkan model data yang solid jika Anda memiliki banyak pengembang yang bekerja secara paralel.

Tetapi kemudian saya memikirkannya sedikit lebih banyak dan saya menyadari bahwa apa yang sebenarnya kami lakukan pada proyek-proyek besar yang lebih sukses adalah "persyaratan pertama".

Serangkaian persyaratan bisnis yang ditentukan dengan baik, mengarah pada serangkaian persyaratan fungsional yang baik. Jika Anda memiliki seperangkat persyaratan fungsional yang baik, maka model data dan spesifikasi modul hanya bisa digunakan tanpa banyak usaha.

Karena ini terlihat sangat cair / tidak spesifik, saya akan melakukan frontend GUI terlebih dahulu - kedengarannya seperti apa yang Anda butuhkan untuk mendapatkan tanggapan, dukungan, waktu, dan umpan balik dari para pemangku kepentingan, bukan? Mereka tidak peduli tentang tabel normalisasi brilian Anda dan batasan kunci asing dan penghapusan cascading. Tapi GUI keren dengan banyak warna mengkilap - well, itu kedudukan tertinggi!

Untuk "database" backend awal, gunakan sesuatu yang sangat sederhana, mungkin hanya kunci / nilai yang disimpan ke file. Saya tidak terbiasa dengan MS Access, jadi tidak tahu apa backend "paling ringan" akan. (meja spreadsheed?) Apa pun yang cepat dan kotor, rencanakan untuk membuangnya.

Jika Anda bisa, gunakan tampilan dan nuansa lucu di GUI untuk memperjelas bahwa itu adalah prototipe. Jika semuanya gagal, gunakan kartu indeks.

Sekarang, mungkin para pemangku kepentingan Anda adalah pakar DB - yang kadang-kadang terjadi pada saya! - dalam hal ini, lakukan beberapa desain DB.

Karena persyaratannya tidak jelas, seseorang dapat mulai dengan model data yang sangat sederhana dengan elemen-elemen kunci yang Anda tahu Anda butuhkan, mungkin hanya tabel dan PK dasar untuk memulai. Sisa data, cerita bersambung ke biner atau XML dan menyimpan BLOB dalam database untuk memulai. Itu seharusnya memungkinkan seseorang untuk mengembangkan UI dan lapisan bisnis (tingkat menengah) tanpa model yang sepenuhnya relasional tetapi Anda masih akan memiliki kegigihan untuk menyimpan dan mengambil dan mencari kunci sederhana sesuai kebutuhan.

Sebagai contoh, mungkin Anda memiliki Person, jadi Anda memiliki PK of Person Id. Atribut lainnya tidak diketahui jadi mulailah dengan tabel Person dengan PK Person Id dan kolom lain yang akan menyimpan Blob, semua data orang.

Setelah persyaratan memadatkan, ambil Gumpalan Anda dan ekstrak semua tabel dan kolom yang diperlukan dan buat model menjadi relasional. Maka itu hanya masalah mengubah persistensi dari BLOB menjadi relasional di lapisan akses data. Tapi yang lainnya, aturan bisnis UI dll akan tetap berfungsi. Catatan, ini menambah waktu untuk proyek tetapi memberikan fleksibilitas penuh untuk menambah dan menjatuhkan hal-hal yang diperlukan tanpa mengubah model relasional sampai semuanya menjadi lebih kencang.

Pencarian mungkin tertunda karena Anda tidak dapat meminta BLOB sehingga model stabil, mulai menyimpan data Anda yang perlu dicari di kolom relasional.

Pada dasarnya Anda mulai dengan model tabular dan beralih ke model relasional ketika proyek berlangsung.

Atau, tegaskan persyaratan sebelum pekerjaan dimulai sehingga model relasional dapat dikembangkan pada awalnya.

Secara umum saya pikir kode datang setelah data karena kode akan memanipulasi data.

Jika persyaratan tidak jelas, Anda dapat membuat model data interpretasi Anda tentang persyaratan. Mungkin yang terbaik adalah menuliskan beberapa persyaratan dan mengirimkannya ke atasan Anda, lalu mereka memiliki sesuatu untuk ditembak. Atau buat gui dulu, tergantung dari jenis majikan mana yang paling baik :)