Haruskah Anda mendesain database sebelum kode aplikasi ditulis?


57

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

  1. Rancang basis data sebaik mungkin sebelum Anda menulis kode aplikasi apa pun . Ini memberi Anda keuntungan memiliki struktur data dasar untuk bekerja. Kelemahan dari ini, menurut pendapat saya, adalah Anda akan memiliki banyak perubahan sebagai spesifik aplikasi yang mempengaruhi apa / di mana / bagaimana perubahan data sepanjang siklus pengembangan aplikasi.
  2. Desain 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?


Bagilah dan Taklukkan dengan SDLC
Premraj

1
Anda mungkin menemukan flywaydb.org menarik. Hal ini memungkinkan Anda untuk mengontrol versi skema database Anda.
Thorbjørn Ravn Andersen

Jawaban:


41

Selain jawaban lain ...

Menangkap model konseptual Anda terlebih dahulu 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 dan 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 memecah tabel, mengubah hubungan, dll. Akan terjadi, tetapi di "pulau" yang dilokalkan, dan model + desain dasar Anda tidak akan berubah.


6
Dan stabilitas itu penting, karena nama tabel dan tampilan, nama kolom, nama prosedur tersimpan, dll., Adalah antarmuka publik basis data. (Dan cepat atau lambat akan ada banyak aplikasi berbagi antarmuka itu.)
Mike Sherrill 'Cat Recall'

Saya akan mengatakan ini adalah pendekatan yang cukup ideal, pengalaman saya adalah bahwa perubahan drastis terjadi dari waktu ke waktu yang kita butuhkan adalah menjadi gesit dan cepat beradaptasi dengan persyaratan baru dan terus refactoring.
zinking

@inkink: Saya melakukan hal Agile saat ini.
gbn

@ GBN, Maaf untuk menanyakan pertanyaan di bawah ini di sini. Saya tidak tahu bagaimana menangani skenario. Silakan lihat. stackoverflow.com/questions/46285924/… . Mohon saran saya solusi yang lebih baik.
RGS

27

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

Saya kira itu memberikan suara saya pada pilihan Anda 2 dan saya kira saya mungkin akan kedinginan dalam hal ini!


4
Agile dan basis data berjalan seiring dengan peringatan. Agile adalah garis batas untuk VLDBs: mungkin tidak ada cukup waktu untuk memvalidasi dan menguji perubahan pada miliar tabel baris di antara kiriman. Dan "pengembangan gesit" tidak sama dengan "perubahan grosir" karena kurangnya pemikiran ke depan
gbn

2
Tidak bisa setuju lagi: kurangnya pemikiran tetapi saya tidak berpikir itu relevan dengan pertanyaan. Ini bukan tentang apakah Anda harus mendekati desain secara serampangan tetapi apakah atau tidak model data Anda harus berkembang seperti aplikasi. Masalah VLDB membutuhkan pengeditan yang akan saya tambahkan.
Mark Storey-Smith

3
Saya membaca pertanyaan sebagai "aplikasi baru tanpa DB", bukan "aplikasi yang ada yang membutuhkan perubahan pada DB"
gbn

Demikian juga, saya kehilangan poin Anda di suatu tempat :) Satu untuk diajak ngobrol?
Mark Storey-Smith

4
Memberi +1 untuk sentimen umum jawaban Anda, tetapi "Memodifikasi skema basis data tidak pernah semudah memodifikasi kode" benar-benar tergantung pada seberapa banyak kode yang Anda miliki (dan berapa lama itu). IMO sebaliknya lebih umum benar
Jack Douglas

12

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. Cakupan creep - Anda mengizinkan persyaratan baru untuk diperkenalkan pada waktu yang tidak tepat.
  2. Persyaratan Bisnis yang Tidak Memadai - 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.


7
Menambahkan banyak persyaratan baru selama proyek tidak "tidak pantas". Ini adalah sesuatu yang harus didukung dan didorong oleh metode pengembangan Anda oleh www.agilemanifesto.org/principles.html
nvogel

1
Saya sangat menyadari beberapa prinsip pengembangan tangkas dan telah menjadi pendukung mereka dalam kapasitas penyimpanan data di mana masuk akal untuk bisnis. Terima kasih atas komentar Anda.
RobPaller

11

Saya telah 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 mendapat 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 di antara 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 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 adalah penemuan persyaratan yang lebih baik. Tetapi idenya adalah merancang aplikasi terlebih dahulu, tanpa menulis kode apa pun. Saya sudah mulai melakukan ini dalam skala kecil, dan itu berhasil! Meskipun ada masalah di lingkungan saya, ini membantu saya mendapatkan basis data yang dirancang lebih baik sejak awal. Saya belajar bahwa kolom harus pindah ke tabel induk baru karena ada beberapa tipe. Saya mengetahui bahwa daftar kerja harus memiliki pesanan tetap yang tidak berasal dari sistem pesanan terintegrasi. Saya belajar segala macam hal!

Menurut pendapat saya, ini adalah kemenangan besar.


+1 Jawaban bagus. Pengembangan persyaratan yang difasilitasi adalah BESAR plus dalam proyek berbagai pemangku kepentingan.
Zayne S Halsall

10

Untuk sebagian besar tujuan saya akan memilih Opsi 2: Membangun database secara paralel dengan komponen lainnya. Sedapat mungkin mengambil pendekatan berulang dan memberikan fungsionalitas 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 untuk data berukuran realistis harus dilakukan dalam setiap iterasi tanpa gagal.


2
Tidakkah Anda berpikir bahwa pemikiran di muka diperlukan untuk mendefinisikan model konseptual?
gbn

Beberapa pemikiran di muka mungkin berguna tetapi berusaha untuk mendefinisikan seluruh model di muka biasanya kontraproduktif. Model harus selaras dengan persyaratan bisnis dan sesuai dengan hasil proyek (termasuk aplikasi) ketika mereka berkembang. Anda tidak dapat dan seharusnya tidak mengharapkan hal-hal itu tidak berubah. Juga membuat seluruh model dimuka benar-benar dapat menghambat pengembangan lain karena kebutuhan untuk membuat antarmuka dummy untuk mendukung bagian skema yang belum digunakan.
nvogel

Saya curiga @dportas dan saya bekerja di lingkungan yang sama :)
Mark Storey-Smith

9

Dalam dunia arsitektur, frasa "Form Follows Function" diciptakan dan kemudian dipatuhi ketika membangun gedung-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 secara berdampingan, tabel-tabel tersebut akan tampak tidak memiliki alasan 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 sederhana sebagai unit penyimpanan data.

Insentif untuk menggunakan database harus melihatnya dengan benar: sebagai RDBMS. Ya, Sistem Manajemen Basis Data Relasional . 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.


1
@RolandoMySQLDBA, Anda berasumsi bahwa desain database yang dibangun selama pengembangan aplikasi akan menjadi desain yang lebih buruk daripada yang dibangun sebelumnya? Mengapa? Yang sebaliknya sering benar.
nvogel

1
@dportas: Penekanan saya adalah pada opsi 1 dalam hal meminimalkan perubahan dalam desain DB. Saya menghabiskan 2/3 dari pemrograman karier teknologi saya di toko-toko di mana model data yang sangat kompleks dan infrastruktur sedang berubah hampir setiap bulan karena kemauan. Saya merasa ngeri terhadap perubahan seperti itu karena kebutuhan dan tujuan bisnis tidak terukir. Saya sekolah yang cukup tua dalam hal ini. Tidak ada salahnya menjadi sedikit maverick selama desainnya tidak menghasilkan banyak 'hutang teknis' (Ya, saya membaca jawaban Anda) di ujung jalan.
RolandoMySQLDBA

2
Memberi +1 untuk 'menggunakan RDBMS sebagai basis data relasional bukan bit-bucket untuk array' - pendekatan apa pun yang Anda ambil
Jack Douglas

2
@dportas: walaupun ini benar (aturan bisnis berubah), db yang dirancang dengan baik tidak akan berubah secara radikal antara iterasi (atau sprint, atau apa pun) dan lainnya, karena mencerminkan semua struktur data yang relevan dari proses kerja. Jika ini terjadi (perubahan radikal), berarti gagal dalam aturan bisnis menangkap kegiatan.
Fabricio Araujo

3
@dportas: tidak semua perubahan DB, hanya yang RADIKAL. Perubahan kecil adalah bagian dari bisnis melakukan perangkat lunak. Tetapi harus membagi data dalam 2 database yang berbeda di tengah pekerjaan adalah kegagalan pada desain dan aturan bisnis menangkap. (Itu benar-benar terjadi pada saya.
Fabricio Araujo

9

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

Alur kerja khas saya, jika bekerja sendiri adalah:

  1. Tentukan apa yang perlu dilakukan aplikasi
  2. Lihat 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 bisa 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 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)


1
Kasus untuk opsi 2 adalah bahwa dengan metodologi tangkas Anda tidak tahu 1, 2, atau 3 di luar apa yang dicakup untuk sprint berikutnya. Perubahan tidak bisa dihindari, dalam ruang lingkup, persyaratan dan harapan.
Mark Storey-Smith

8

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

Mengapa? Tidak peduli apa metodologi / bahasa / toolset yang saya gunakan, jika semua data yang relevan dirancang dengan baik dan disimpan dalam 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 didorong; lincah atau air terjun. Jika datanya ada, saya bisa 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 di sana atau bahkan jika itu ada tetapi (tidak) terstruktur dengan cara saya tidak dapat mengambil informasi yang saya butuhkan - bagaimana cara mengkodekannya?


7

Seperti biasanya, itu tergantung;)

Sebagai contoh, anggaplah kita memiliki prototipe kerja ukuran kecil yang dikembangkan dengan Python dan menggunakan file datar, dan pengguna senang dengan fitur-fitur prototipe, jadi yang perlu kita lakukan hanyalah 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 seperti itu, desain 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 tabel OLTP langsung tanpa downtime dan dengan risiko rendah, kami merasa nyaman dengan kemungkinan refactoring basis data.

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.