it-swarm.asia

Haruskah Anda mendesain database sebelum kode aplikasi ditulis?

Apa cara termudah dan paling efisien untuk merancang basis data? Dari sudut pandang saya, ada beberapa opsi untuk desain penyimpanan data aplikasi:

  1. Desain database sebaik mungkin pada awalnya sebelum menulis kode aplikasi apa pun. Ini memberi Anda keuntungan memiliki struktur data dasar untuk bekerja. Kelemahan dari ini, menurut saya, adalah Anda akan memiliki banyak perubahan sebagai spesifik aplikasi yang memengaruhi perubahan data apa/di mana/bagaimana sepanjang siklus pengembangan aplikasi.
  2. Rancang basis data saat aplikasi membuahkan hasil . Ketika Anda membutuhkan beberapa objek database saat Anda menulis aplikasi, Anda mengembangkan paralel database (secara kronologis) ke aplikasi. Keuntungannya akan lebih sedikit perubahan pada struktur database seperti yang saya lihat. Kerugiannya adalah pembagian waktu dan upaya pengembangan antara kode aplikasi dan pengembangan basis data.

Dalam pengalaman Anda, apa yang Anda temukan sebagai metode yang paling produktif dan efisien?

57
Thomas Stringer

Selain jawaban lain ...

Menangkap model konseptual Anda terlebih dahul harus mendefinisikan ruang lingkup dan persyaratan. Dari ini, Anda dapat memperoleh model data logis dan fisik Anda.

Setelah ini sebagian besar statis, maka Anda memiliki database yang stabil untuk membangun aplikasi Anda. Ini bertentangan dengan opsi pertama Anda.

Poin kedua Anda akan berakhir dengan bola lumpur yang berantakan, tidak dapat dipelihara . Model data tidak akan pernah diperbaiki: jika Anda tidak mendesainnya di muka, Anda tidak akan punya waktu untuk memperbaikinya sebelum pengiriman. Anda akan terlalu sibuk meretas hal-hal bersama.

Perubahan kecil pada skema, menggabungkan atau memisahkan tabel, mengubah hubungan, dll. Akan terjadi, tetapi di "pulau" yang dilokalkan, dan model + desain dasar Anda tidak akan berubah.

42
gbn

Anda akan kesulitan menemukan departemen perangkat lunak modern yang tidak mengoperasikan beberapa varian Agile. DBA sebagai perbandingan terjebak di zaman kegelapan, dengan jenis pemikiran bahwa jawaban RobPaller masih merupakan tempat umum.

Memodifikasi skema basis data tidak pernah semudah memodifikasi kode, itulah sebabnya ada keengganan untuk merangkul pendekatan tangkas dalam pengembangan dan pemeliharaan basis data. Sekarang kita memiliki alat dan teknik untuk beroperasi dengan cara yang mirip dengan pengembang, kita harus melakukannya. Hanya karena tidak mudah untuk mengubah skema, bukan berarti Anda tidak bisa dan Anda tidak seharusnya.

Saya tidak menganjurkan pendekatan sembarangan untuk desain database (lihat komentar), hanya sebuah pendekatan yang lebih dekat mencerminkan bahwa dari tim pengembangan lincah. Jika Anda adalah bagian dari proyek lincah, Anda tidak akan memiliki persyaratan untuk pekerjaan yang mungkin ( atau mungkin tidak ) terjadi di masa depan sehingga desain untuk apa yang Anda tahu dibutuhkan, bukan apa yang mungkin menjadi.

Saya kira itu menempatkan suara saya dengan pilihan Anda 2 dan saya kira saya mungkin mendapati diri saya berdiri dingin dalam hal ini!

27

Model data logis Anda harus secara efektif menangkap persyaratan bisnis aplikasi Anda. Desain basis data fisik Anda harus didasarkan pada model data logis yang dikombinasikan dengan perubahan yang diperlukan yang menurut Anda sebagai DBA diperlukan untuk memaksimalkan efisiensi RDBMS Anda.

Jika Anda menemukan bahwa Anda harus membuat banyak perubahan pada desain database yang mendasarinya melalui siklus hidup pengembangan perangkat lunak aplikasi Anda, itu menandakan dua hal:

  1. Scope creep - Anda mengizinkan persyaratan baru untuk diperkenalkan pada waktu yang tidak tepat.
  2. Persyaratan Bisnis yang Tidak Cukup - Pemodel data Anda (atau analis sistem) tidak cukup menerjemahkan persyaratan dari analis bisnis. Ini menghasilkan model data yang tidak lengkap atau salah untuk mendukung persyaratan aplikasi Anda.

Yang dikatakan begitu aplikasi telah diserahkan ke produksi, tidak jarang harus kembali dan membuat perubahan berulang pada model data untuk mendukung evolusi alami aplikasi atau proses bisnis yang mendasarinya.

Semoga ini membantu.

12
RobPaller

Saya memiliki kemewahan merancang beberapa database kompleksitas menengah, semua digunakan dalam bisnis, dengan berbagai ujung depan termasuk web, Access, dan C #.

Biasanya, saya sudah duduk dan mengerjakan skema database terlebih dahulu. Ini selalu masuk akal bagi saya. Namun, belum ada satu pun kasus di mana saya tidak akhirnya membuat perubahan, menambahkan tabel baru, atau hidup dengan aspek-aspek yang mengganggu saya dan pada dasarnya sudah terlambat untuk memperbaikinya.

Saya tidak berpikir obatnya adalah dengan menulis kode terlebih dahulu. Dan saya tidak berpikir masalahnya adalah "persyaratan bisnis yang tidak mencukupi" atau setidaknya, tidak satu pun yang bisa diselesaikan sepenuhnya. Para pengguna tidak tahu apa yang mereka butuhkan dan saya tidak memiliki kekuatan untuk membuat mereka berpikir lebih keras atau lebih pintar atau lebih sadar atau menjawab pertanyaan saya dengan lebih baik. Atau mereka berdebat dan saya diperintahkan untuk melakukan sesuatu dengan cara tertentu.

Sistem yang saya bangun biasanya di area baru yang belum pernah dikunjungi sebelumnya. Saya tidak memiliki dukungan dari organisasi, sumber daya, atau alat untuk melakukan pekerjaan seperti yang bisa dilakukan oleh tim pengembangan profesional desain papan atas yang dibayar sebagai tim sepuluh kali lipat dari yang saya hasilkan untuk membangun sesuatu di dua kali lipat waktu.

Saya BAIK pada apa yang saya lakukan. Tetapi hanya ada satu dari saya yang melakukannya di lingkungan yang "tidak melakukan pengembangan."

Semua yang dikatakan, saya semakin baik dalam menemukan aturan bisnis. Dan saya melihat semacam opsi ketiga:

Sebelum Anda mendesain database, dan sebelum menulis kode apa pun, gambarkan layar kasar yang menunjukkan bagaimana aplikasi akan bekerja. Mereka harus digambar tangan untuk mencegah siapa pun mengomentari font atau ukuran atau dimensi - Anda hanya ingin berfungsi.

Dengan transparansi dan potongan-potongan kertas Anda dapat bertukar masuk dan keluar, memiliki satu orang menjadi komputer, dua menjadi pengguna materi-ahli non-teknis (dua sehingga mereka berbicara dengan suara keras) dan satu orang di sana sebagai fasilitator yang membuat catatan dan menggambar para pengguna tentang proses pemikiran dan kebingungan mereka. Para pengguna "klik" dan seret dan tulis di dalam kotak, "komputer" memperbarui layar, dan semua orang dapat merasakan desainnya. Anda akan mempelajari hal-hal yang tidak dapat Anda pelajari sampai jauh ke dalam proses pengembangan.

Mungkin saya bertentangan dengan diri saya sendiri - mungkin itu IS penemuan persyaratan yang lebih baik. Tetapi idenya adalah untuk merancang aplikasi terlebih dahulu, tanpa menulis kode apa pun. Saya sudah mulai melakukan ini dalam skala kecil, dan itu berhasil ! Terlepas dari masalah di lingkungan saya, ini membantu saya mendapatkan database yang dirancang lebih baik dari awal. Saya belajar bahwa kolom harus pindah ke tabel induk baru karena ada beberapa jenis. Saya belajar bahwa daftar kerja harus memiliki pesanan berdiri yang tidak datang dari sistem pemesanan terintegrasi. Saya belajar banyak hal!

Menurut pendapat saya, ini adalah kemenangan besar.

11
ErikE

Untuk sebagian besar tujuan saya akan memilih Opsi 2: Membangun database secara paralel dengan komponen lainnya. Sedapat mungkin mengambil pendekatan berulang dan memberikan fungsi ujung ke ujung saat Anda membangun masing-masing bagian.

Ini memang membutuhkan sejumlah disiplin proyek. Terapkan normalisasi secara ketat (Boyce-Codd/Fifth Normal Form) setiap kali Anda mengubah database sehingga Anda mempertahankan kualitas dan tidak berakhir dengan model ad-hoc dan tidak konsisten. Jadilah seagresif mungkin dengan aturan bisnis dan kendala basis data petugas. Jika ragu, lebih baik menegakkan batasan lebih awal - Anda selalu bisa menghilangkannya nanti. Jadilah cerdas tentang urutan Anda menerapkan komponen arsitektur untuk meminimalkan utang teknis. Memiliki seperangkat pedoman desain basis data yang baik yang dibeli oleh semua tim pengembang.

Semua ini tentu saja harus berjalan seiring dengan praktik-praktik rekayasa pengembangan lainnya yang baik: integrasi berkelanjutan, otomasi pengujian dan yang terpenting dari perspektif basis data, membuat data uji. Pembuatan data uji dari data berukuran realistis harus dilakukan dalam setiap iterasi tanpa gagal.

10
nvogel

Dalam dunia arsitektur, frasa "Function Follows Function" diciptakan dan kemudian dipatuhi ketika membangun gedung tinggi. Hal yang sama harus diterapkan pada infrastruktur DB dan pengembangan aplikasi.

Bayangkan menulis aplikasi, memutuskan on-the-fly bahwa Anda memerlukan meja di sini dan meja di sana. Ketika aplikasi Anda selesai, Anda memiliki sejumlah besar tabel yang diperlakukan sebagai array. Melihat semua tabel berdampingan, tabel-tabel itu pasti akan tampak tidak memiliki rima atau alasan.

Sayangnya, beberapa toko pengembang akan mengambil sesuatu seperti memcached, memuatnya dengan data dalam RAM (sehingga memperlakukannya seperti saluran data), dan memiliki database, seperti MySQL atau PostgreSQL, berperilaku seperti unit penyimpanan data.

Insentif untuk menggunakan database harus melihatnya dengan benar: sebagai RDBMS. Ya, a Relasional Sistem Manajemen Basis Data. Saat Anda menggunakan RDBMS, tujuan Anda di muka tidak hanya untuk membuat tabel untuk penyimpanan, tetapi juga untuk pengambilan. Hubungan antara tabel harus dimodelkan setelah data yang ingin Anda lihat dan bagaimana disajikan. Ini harus didasarkan pada keterpaduan dan integritas data bersama dengan aturan bisnis yang dikenal. Aturan bisnis tersebut dapat dikodekan dalam aplikasi Anda (Perl, Python, Ruby, Java, dll) atau dalam database .

KESIMPULAN

Saya pasti akan memilih opsi 1. Dibutuhkan perencanaan yang tepat, pemodelan data, dan analisis data yang sedang berlangsung. Namun, ini harus meminimalkan perubahan database dalam jangka panjang.

9
RolandoMySQLDBA

Saya pikir itu harus dilakukan sebelum ada yang sebenarnya kode untuk aplikasi, tetapi tidak sebelum aplikasi dirancang.

Alur kerja khas saya, jika bekerja sendiri adalah:

  1. Tentukan apa yang perlu dilakukan aplikasi
  2. Lihat untuk melihat apakah ada tugas yang dapat diuraikan untuk komponen yang dapat digunakan kembali
  3. Tentukan bagaimana setiap tugas perlu berinteraksi dengan penyimpanan data - pertanyaan apa yang akan mereka tanyakan dari data, seberapa sering mereka akan menulis, dll.
  4. Rancang basis data sehingga harus dapat menjawab semua pertanyaan yang perlu kita tanyakan, dan harus bekerja dengan baik untuk tugas-tugas yang paling sering.
  5. Tulis aplikasinya.

Karena saya sering bekerja sebagai bagian dari tim, dan kami tersebar secara geografis (dan melintasi zona waktu), kami cenderung mengadakan pertemuan perdana:

  1. Tentukan apa yang perlu dilakukan aplikasi.
  2. Tentukan di mana poin yang baik untuk memecah aplikasi menjadi komponen mandiri
  3. Tentukan bagaimana masing-masing komponen perlu berinteraksi dengan yang lain.
  4. Setuju pada API untuk masing-masing interaksi.

Kemudian, kita kembali ke rumah, menulis bagian kita, dan jika suatu komponen membutuhkan penyimpanan lokalnya sendiri, selama pengelola untuk bagian itu menjaga API ke modul mereka konsisten. Penyimpanan data utama ditangani sebagai modul dengan APInya sendiri, dan orang-orang diharapkan untuk menulisnya. (dalam kasus di mana kecepatan DB sangat penting, API adalah definisi tabel, dan jika perubahan dilakukan, kami menggunakan tampilan atau mekanisme lain untuk menyajikan versi yang lebih lama hingga semua modul dapat diperbarui)

9
Joe

Saya ingat aturan berikut: "Anda hanya bisa mendapatkan dari database informasi yang Anda punya data untuk dihasilkan". Jadi, saya mendesain database dulu kodenya.

Mengapa? Apa pun metodologi/bahasa/toolset yang saya gunakan, jika semua data yang relevan dirancang dan disimpan dengan baik di DB, saya dapat mengambilnya. Tidak masalah jika dalam C #/Delphi/FORTRAN/COBOL/Assembly/VBA atau Crystal Reports; OO dirancang atau acara/data/apa pun yang digerakkan; gesit atau air terjun. Jika data ada di sana, saya dapat mengambilnya jika alat yang saya gunakan dapat terhubung ke database. Saya dapat membuat laporan penjualan jika saya dapat MEMILIH pesanan untuk pendapatan kuartal - bahkan jika saya harus menuliskannya byte demi byte pada Assembly.

Jika data yang relevan tidak ada atau bahkan ada di sana tetapi (tidak) terstruktur dengan cara saya tidak dapat mengambil informasi yang saya butuhkan - bagaimana cara mengkodekannya?

8
Fabricio Araujo

Seperti biasanya, itu tergantung;)

Sebagai contoh, anggaplah kita memiliki prototipe kerja ukuran kecil yang dikembangkan di Python dan menggunakan file datar, dan pengguna senang dengan fitur-fitur prototipe, jadi yang perlu kita lakukan adalah dengan memproduksinya, menggunakan RDBMS sebagai ujung belakangnya.Ketika hal ini terjadi, masuk akal untuk berharap melakukannya dengan benar pertama kali - masalahnya kecil dan terdefinisi dengan baik.Dalam kasus-kasus seperti merancang di muka layak dilakukan.

Di sisi lain, ketika kita menemukan persyaratan dalam lingkungan Agile, kita perlu beberapa iterasi untuk memahaminya dengan lebih baik. Dalam situasi seperti itu, database berevolusi dengan aplikasi lainnya. Inilah yang biasanya kita lakukan. Karena kita dapat melakukan refactor langsung tabel OLTP tanpa downtime dan dengan risiko rendah, kami merasa nyaman dengan kemungkinan refactoring basis data.

7
A-K