Kode Pertama vs. Database Pertama


77

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.)



6
@gnat: Itu sangat berbeda.
Robert Harvey

1
Jika ini ditutup sebagai duplikat, itu harus merupakan duplikat dari pertanyaan ini . Jawaban dan pertanyaannya lebih sesuai dengan apa yang saya tanyakan.
RubberDuck

1
@ Mawg itu adalah proyek kerja. Saya telah mendorong mundur sebanyak mungkin tentang mendapatkan persyaratan dipaku. Pekerjaan harus dimulai dari ini dan tidak ada lagi yang bisa saya lakukan.
RubberDuck

4
Errrm, pekerjaan baru? Saya tahu saya akan melakukannya. Tetapi sebagai freelancer 30 tahun saya merasa mudah untuk pergi sebelum itu benar-benar menyentuh penggemar (beberapa orang hanya tidak bisa membantu), tetapi saya menyadari bahwa itu tidak begitu mudah untuk semua. Tetaplah jika Anda harus (tidak ada majikan yang sebanding di daerah, dll), tetapi jangan tinggal jika mulai mempengaruhi Anda
Mawg

Jawaban:


85

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.


1
"Basis data adalah detail". Terima kasih banyak untuk tautannya. Saya sepenuh hati percaya bahwa saya akan dapat menangani proyek ini meninggalkan database sebagai keputusan yang ditangguhkan setelah menonton pembicaraan itu.
RubberDuck

6
Dan hanya untuk menempatkan nama di atasnya: Praktek-praktek ini semua (bisa dibilang yang ) praktek penting dalam pembangunan Agile (pembangunan inkremental, hal paling sederhana yang bisa bekerja, uji-didorong, kebutuhan pengguna pertama ...).
sleske

8
Saya ingin kembali dan terima kasih lagi. Saya memiliki seluruh tingkat menengah saya yang bekerja tanpa database dan saya sekarang memiliki pemahaman yang baik tentang bagaimana data harus dipertahankan. Saya tidak bisa cukup berterima kasih. Saya akan memilih lagi jika saya bisa.
RubberDuck

12
Jika Anda benar-benar menangkap semua persyaratan melalui metode kode-pertama Anda, dan Anda benar-benar mengungkapkan semua persyaratan itu dalam basis data akhir Anda , saya bisa setuju dengan jawaban ini. Tetapi saya telah melihat banyak, banyak proyek di mana kepuasan mendapatkan sesuatu yang "bekerja" menghasilkan sikap bahwa "jika itu berfungsi, database harus cukup baik", bahkan ketika itu adalah desain database yang MENGERIKAN , dengan masalah kinerja yang serius dan serius kemudian. Juga, banyak orang tampaknya berpikir jika kode memvalidasi data Anda tidak perlu PERIKSA atau kendala KUNCI ASING. Kamu lakukan .
Ross Presser

2
Mungkin ini tercakup dalam video - sayangnya saya tidak bisa sampai sekarang - tetapi keuntungan lain dari pendekatan tambahan adalah bahwa ketika dilakukan dengan benar akan membantu memperkuat spesifikasi yang tidak jelas. "Apakah layar ini terlihat seperti menangkap semua informasi kontak yang Anda butuhkan? Apakah bidang-bidangnya diatur dalam urutan yang masuk akal dengan alur kerja Anda?" Mampu mengajukan pertanyaan-pertanyaan ini - dengan sesuatu yang konkret sebagai referensi - adalah IME sering satu - satunya cara untuk mendapatkan informasi yang Anda butuhkan.
David

17

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.


Saya setuju dengan sepenuh hati, tetapi itu tidak akan terjadi pada yang satu ini. Terima kasih atas waktu Anda.
RubberDuck

9
Jika Anda tidak punya waktu untuk melakukannya dengan benar, di mana Anda akan menemukan waktu untuk melakukannya?
Walter Mitty

Siapa yang mengatakan sesuatu tentang tidak melakukannya dengan benar @ WalkerMitty? Silakan lihat tautan video dalam jawaban yang diterima. Basis data adalah detail yang tidak perlu ada di tempat untuk menyelesaikan 95% dari perangkat lunak.
RubberDuck

1
Saya mengambil "itu tidak akan terjadi" berarti Anda akan melanjutkan ke kode tanpa petunjuk apa pun informasi yang diperlukan oleh para pemangku kepentingan dari sistem. Saya pikir James memberi Anda nasihat yang sangat baik tentang melakukan analisis sistem dasar tanpa menjadi terperosok dalam analisis kelumpuhan.
Walter Mitty

Anda salah mengerti saya @WalterMitty. Saya telah mengambil pendekatan loop umpan balik. Saya akan membangun apa yang saya pikir seharusnya (tanpa database) dan kemudian membawanya ke pengguna. Ubah program. Ulangi. Setelah beberapa iterasi, saya harus tahu persis seperti apa database itu. Seperti yang saya pahami, pendekatan Agile dirancang khusus untuk mengatasi persyaratan yang tidak jelas. Itu terlihat dalam diriku dengan baik dalam proyek ini.
RubberDuck

12

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.


Itu semua adalah hal yang sangat benar, dan pada kenyataannya ini akan menggantikan "non-proses" dan spreadsheet, tetapi saya gagal melihat bagaimana ini merupakan jawaban untuk pertanyaan saya. Bisakah Anda mengklarifikasi?
RubberDuck

1
@RubberDuck Saya menambahkan klarifikasi di akhir jawaban saya.
Tulains Córdova

11

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.


Inilah tepatnya cara saya biasanya bekerja. Persyaratan dulu , ya. Betapa aku berharap bisa mengeluarkan persyaratan yang kuat dari seseorang sekarang.
RubberDuck

Persyaratan terlebih dahulu, meskipun Anda tidak harus menunggu sampai persyaratan selesai (tidak pernah ada). Pergi begitu Anda memiliki cukup untuk memiliki gagasan tentang apa tujuan dari aplikasi tersebut, kemudian dapatkan lebih banyak ketika Anda membutuhkannya.
sleske

@sleske - Seorang analis yang baik harus merasakan bagian-bagian yang lebih "dinamis" (yaitu samar dan dapat diubah) dari persyaratan dan membangun fleksibilitas dalam desain untuk dengan mudah mengatasi keinginan pengguna.
James Anderson

1
@JamesAnderson: Sebenarnya, saya penggemar berat prinsip pengembangan lincah, di mana Anda biasanya hanya mendesain apa yang Anda butuhkan sekarang , kecuali Anda tahu Anda tidak dapat mengubah desain nanti (jarang terjadi). Tapi aku mulai keluar topik ...
sleske

8

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.


3
+1 bukan untuk "kode pertama" atau "basis data pertama" tetapi "non-fungsional gui-prototipe pertama" (alias "prototyping cepat"), karena dengan tidak adanya persyaratan, prototipe gui membantu memperjelas persyaratan dengan pengguna akhir.
k3b

1
Benar, tetapi itu juga membuat mereka percaya bahwa aplikasi sebagus dilakukan. Saya telah dibakar seperti itu sebelumnya & sekarang menuntut agar kami mendapatkan persyaratan langsung terlebih dahulu
Mawg

@ Mawg ya, sayangnya itu berbahaya. Salah satu pilihan (setidaknya di Jawa) adalah menggunakan "tampilan dan nuansa" yang aneh untuk memperjelas bahwa ini adalah prototipe.
user949300

Jika Anda tidak tahu ke mana Anda akan pergi, kode apa pun akan membawa Anda ke sana.

-1

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.


Dengan cara ini kegilaan terletak. Jangan pernah menyimpan data sampai Anda siap untuk tetap menyimpan data. Normalisasi data setelah faktanya adalah mimpi buruk.
RubberDuck

1
Ada perbedaan antara kegigihan dan normalisasi. Pertanyaan yang hanya bisa Anda jawab adalah apakah saya perlu bertahan saja, atau bertahan dan menormalkan. Model data adalah model, jika tidak ada persyaratan, maka sulit untuk memodelkan sesuatu secara relasional.
Jon Raynor

-2

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 :)


3
ini tampaknya tidak menawarkan sesuatu yang substansial atas poin yang dibuat dan dijelaskan dalam 5 jawaban sebelumnya
nyamuk

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.