Apa cara terbaik untuk menentukan kapan waktu yang tepat untuk menggunakan database?


13

Saya memulai karir pemrograman saya dalam pengembangan web menggunakan PHP dan MySQL. Saya cukup terbiasa menggunakan db untuk penyimpanan data paling dinamis serta beberapa pengaturan / parameter data. Kadang-kadang akan ada banyak data sementara entri kali lain dalam tabel akan sedikit. Bagi saya ini hanya tampak alami dan sejauh yang saya tahu ini kurang lebih merupakan pendekatan yang dapat diterima dalam pengembangan web. (Tolong koreksi saya jika saya salah ...)

Saya mempelajari aplikasi desktop sekarang dan kecenderungan alami saya adalah menggunakan lagi db untuk menyimpan banyak informasi yang akan dihasilkan melalui penggunaan aplikasi. Namun, sejauh yang saya tahu saya tidak melihat aplikasi (yang saya gunakan) sangat sering menggunakan db. [EDIT: Sejak itu telah ditunjukkan bahwa ini adalah asumsi yang salah dalam banyak aplikasi yang menggunakan dbs ringan yang tertanam dalam program itu sendiri.] Apa alasannya? Pada titik mana yang tepat untuk menggunakan db? Apakah ada standar dalam hal ini? Juga apa alasan untuk TIDAK menggunakan db untuk mengembangkan aplikasi desktop?


2
"Namun, sejauh yang saya tahu saya tidak melihat aplikasi (yang saya gunakan) sangat sering menggunakan db"? Berdasarkan apa? Jika mereka menggunakan SQLite, bagaimana Anda bisa tahu apakah mereka menggunakan atau tidak menggunakan database?
S.Lott

Itulah mengapa saya mengatakan sejauh yang saya tahu karena saya tahu ada kemungkinan saya salah. Saya pikir mungkin ada beberapa aplikasi yang menggunakan embedded db's ... Apakah cukup umum untuk aplikasi menggunakan dbs?
Kenneth

@ Kenenneth: Silakan Google untuk embedded DB's seperti SQLite. Ada banyak. Mereka banyak digunakan. AFAIK, iOS Apple menggunakannya untuk semua kegigihan. Silakan Google.
S.Lott

2
Saya banyak Google. Kadang-kadang meskipun tidak ada yang menggantikan pendapat berpengalaman yang Anda tidak selalu dapat menemukan googling.
Kenneth

1
Saya pikir komentar ini cukup untuk memperbaiki asumsi yang salah. Saya minta maaf atas kesalahan ini. Saya merasa menggunakan campuran googling dan bertanya yang sehat. Terkadang tidak ada pengganti untuk IMHO yang terakhir. Sekarang googling saya akan lebih terarah dan lebih produktif.
Kenneth

Jawaban:


4

jika aplikasi Anda berorientasi pada dokumen, simpan sesuatu dalam file dokumen

jika aplikasi Anda menangani lebih banyak data terstruktur, terlalu banyak untuk satu dokumen (seperti dokumen XML), gunakan database


7

Suatu sistem basis data secara tradisional dipandang sebagai layanan yang relatif berat - yang Anda tidak perlu ingin instal pada setiap mesin klien di luar sana. Saya benar-benar berada dalam situasi (pengembangan aplikasi GUI desktop di mana banyak data yang perlu disimpan) di mana sistem DB nyata akan menjadi solusi "ideal" - tetapi karena pada masa itu satu-satunya database yang tersedia relatif berat, kami pergi dengan file data datar sebagai gantinya.

Meskipun ada beberapa database yang lebih ringan di luar sana hari ini, ini masih merupakan argumen yang valid terhadap database sisi klien. Bayangkan beberapa aplikasi desktop kecil sederhana (seperti misalnya, mainan atau game desktop sederhana) yang harus menyimpan beberapa lusin pengaturan dan parameter. Sepertinya cara di atas untuk membuat seseorang menginstal MySQL hanya untuk menjalankan aplikasi Anda.

Dengan pengembangan web, server secara alami adalah back-end, di mana memiliki database adalah hal yang biasa. misalnya. Para pengguna tidak perlu khawatir tentang menginstal database pada akhirnya.


Jadi Anda akan merekomendasikan untuk tidak menggunakan db untuk aplikasi yang berdiri sendiri, kecuali jika volume data yang besar benar-benar menjaminnya?
Kenneth

apa pendapat Anda tentang penggunaan db ringan ... sama dengan db skala penuh?
Kenneth

1
@ Kenenneth: Saya akan mengatakan "itu tergantung". Jika aplikasi membutuhkan volume besar data tabular yang benar-benar membutuhkan DB yang tepat, maka argumen tersebut mungkin cukup kuat untuk mengirimkan aplikasi dengan DB yang ringan. Tetapi jika itu hanya konfigurasi / pengaturan jenis data, maka itu mungkin berlebihan.
Bobby Tables

5

Aplikasi desktop mempertahankan status saat sedang berjalan. Sedangkan pengembangan web biasanya tidak. Jadi, sementara Anda mungkin perlu menyimpan pengaturan pengguna di database di antara pemuatan halaman, dalam aplikasi desktop Anda hanya menyimpannya di memori. Itu sangat mengurangi kebutuhan untuk jenis penyimpanan yang persisten. Saat Anda ingin menyimpan preferensi di antara penggunaan, Anda dapat menyimpan semuanya untuk satu file, atau meletakkannya di suatu tempat seperti registri Windows.

Yang sedang berkata, sistem database digunakan cukup banyak di aplikasi desktop. Jauh sebelum web, aplikasi desktop telah terhubung ke DBMS. Terutama untuk aplikasi yang tidak berbasis dokumen. Meskipun hari ini, dengan ketersediaan mesin ringan yang lebih baik, Anda melihat garis sedikit kabur. Sebagai contoh, saya menggunakan SQLite db's sebagai dokumen di beberapa aplikasi saya.


+1 Jika Anda tidak memiliki masalah persistensi yang kompleks, seperti pembaruan pemblokiran multi-pengguna, multi-lokasi, simultan, database tradisional mungkin berlebihan. Jika data yang dimaksud cukup statis (dapat tumbuh atau ditambahkan, tetapi tidak berevolusi atau diperbarui), dan persaingan / persaingan tidak sering atau buruk (efek samping / pengalaman pengguna untuk menunggu kunci dikunci secara gratis tidak dapat diterima mempertimbangkan pengorbanan kinerja dan kompleksitas), Anda mungkin tidak memerlukan database.
JustinC

4

Satu hal yang Anda mungkin ingin melihat adalah database ringan yang tidak memerlukan layanan database yang sebenarnya berjalan. misalnya di depan Microsoft ada SQL Server Compact , yang gratis, hanya memerlukan satu file untuk database dan beberapa DLL ditambahkan ke aplikasi Anda, dan dari perspektif pengembang, berperilaku sama seperti SQL Server "nyata".

Saya yakin ada opsi serupa di platform lain.


1
Contoh yang sangat mirip di sisi Jawa adalah Derby. Saya pikir ada orang lain juga.
jprete

1
Kedengarannya ini mungkin solusi yang ideal ... Saya sangat menikmati memanfaatkan db! lol
Kenneth

Apakah ada kerugian menggunakan db yang ringan?
Kenneth

@ Kenenneth: Mereka membuat instalasi Anda lebih besar dan dapat meningkatkan basis kode. Tapi itu jauh lebih sedikit daripada menginstal seluruh server database pada klien, yang biasanya hanya dilakukan ketika aplikasi didistribusikan dan membutuhkan database yang lebih besar. The Berkeley DB adalah salah satu yang paling umum digunakan.
Orbling

opsi lain adalah SQLite, yang jauh lebih ringan pada RAM dan ruang disk, dan tidak memiliki batasan arbitrer. Tidak heran itu digunakan oleh semua smartphone dan browser web non-MS.
Javier

2

Pada aplikasi web, penting untuk menyimpan keadaan persisten pada penyimpanan terpusat. Karena aplikasi web biasanya merupakan hambatan pertama, penting untuk dapat mendistribusikannya tanpa harus mempertanyakan salinan mana yang memiliki data (prinsip 'Tidak Dibagikan'). Bukan hanya database, tetapi memcachedsistem antrian juga ada karena alasan yang sama.

Aplikasi desktop tidak memiliki tujuan skalabilitas yang sama. Biasanya, sebagian besar data disimpan secara lokal di setiap workstation. Berbagi data adalah masalah yang berbeda dalam banyak kasus. Itu menghilangkan satu alasan besar untuk menggunakan database.

Aplikasi GUI juga dapat memiliki dokumen kompleks yang dapat ditangani sebagai web objek yang kompleks dalam memori. Normalisasi struktur menjadi skema DB relasional dapat menambah kompleksitas yang signifikan untuk masalah, kadang-kadang lebih mudah untuk hanya membuat serialisasi semuanya dalam satu bytestream tunggal. Banyak kerangka kerja OOP menyertakan beberapa fasilitas hanya untuk itu.

Namun, membuat dokumen yang disimpan dapat dibaca dengan alat di luar aplikasi utama adalah keuntungan besar dalam banyak kasus, jadi baik menggunakan format yang dapat dibaca manusia (XML, JSON, YAML, dll), atau file zip yang menggabungkan beberapa potongan sederhana semakin banyak dan lebih umum.

Pada nada yang sama, menggunakan pustaka database yang dapat disematkan (BDB, Tokyo Cabinet, SQLite, MS-SQL * server Compact, dll.) Adalah pendekatan hebat lainnya.


1

Database dapat berlebihan tetapi mereka biasanya tidak memiliki menjadi. Program yang sangat sederhana tidak membutuhkannya. Jika dokumen Anda dapat memuat dalam memori dalam jumlah waktu yang sepele dan tetap di sana tanpa masalah, Anda tidak benar-benar membutuhkannya untuk banyak program.

Sebagai contoh, pertimbangkan:

#include "superheader.h"

int main()
{
    int row=2, column=2;
    DatabaseType db;
    db.ConnectTo("programDB", "user", "pass");
    db.setTable("messages");
    string hello_world=db.fetch(row, column);
    cout<<hello_world;
    return 0;
}

Yah itu terlalu sederhana, tapi jelas ini terlalu banyak. Tidak ada gunanya memiliki level manajemen data untuk "Hello World"

Biasanya aturan praktis yang saya gunakan adalah menggunakan database jika Anda memiliki banyak set data, terutama jika mereka berbeda secara unik ATAU menggunakan database jika jumlah data agak besar. Database secara umum dikaitkan dengan beberapa overhead, tetapi ada banyak yang tidak benar-benar memiliki banyak. Basis data kecil, ringan, di dalam memori misalnya kadang-kadang berguna untuk proyek-proyek kecil dengan pemrosesan berat, penjadwalan, atau banyak perubahan dinamis pada data.

Ada berbagai gaya pengkodean, sering kali tidak ada yang salah dengan basis data, tetapi kebanyakan dari kita tidak akan bertindak 'sejauh itu' untuk tugas-tugas dasar. Masih ada waktu lain database yang tepat akan menawarkan manfaat kinerja. Cobalah untuk secara khusus memahami perbedaan di mana data akan berada, berapa lama akan ada di sana dan apa yang akan mengubahnya selama umur itu.


1

Menggunakan db selalu merupakan hal yang benar dan dengan implementasi SQLite untuk hampir semua bahasa di luar sana tidak menggunakan satu hanya membuat keputusan desain yang buruk. Satu-satunya alasan untuk tidak menggunakannya adalah jika Anda melakukan pemrograman tertanam atau jenis pemrograman non-aplikasi lainnya. Meminta data dan pengaturan dengan bahasa deklaratif seperti SQL jauh lebih alami daripada melintasi file datar atau objek lain dalam memori dengan sintaksis imperatif. Plus, itu memisahkan operasi data dari kode aplikasi lain yang dalam jangka panjang membuat kode lebih modular dan dapat dipelihara.

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.