Praktik Terbaik: Pola pemrograman aplikasi basis data

Saya telah menulis banyak aplikasi web database (MySQL) sejauh ini, tetapi saya selalu berpikir struktur saya agak canggung. Saya ingin memperbaiki pola pemrograman / desain yang saya gunakan, berharap ada saran di sini. Khususnya, saya tidak dapat menemukan struktur yang melengkapi pendekatan OOP yang merangkum implementasi database (skema). saya

Pikirkan pertanyaan saya dapat dijelaskan dengan contoh terbaik. Ada 2 pendekatan yang saya gunakan sekarang mengatakan saya memiliki objek / kelas Faktur:

pertama adalah menggunakan fungsi anggota statis

class Invoice
{
   int id;
   string ref;
   int customer_id;
   date created;
   date due;

   static id create();
   static bool update(id, field1, field2, ...);
   static bool delete(id);
   static bool get(id);
};

Pendekatan kedua adalah meletakkan segala sesuatu di objek basis data:

class Database extends ProprietaryDBConnecter, Singleton
{
   id createInvoice();
   bool updateInvoice(id, field1, field2, ...);
   bool deleteInvoice(id);
   bool getInvoice(id);

   id createCustomer();
   bool updateCustomer(id, field1, field2, ...);
   bool deleteCustomer(id);
   bool getCustomer(id);

   // etc...
}

Saya menemukan bahwa kedua cara fungsi anggota (SQL) sangat tidak dapat dipisahkan dari "view", dalam "view" menentukan apa yang perlu dimiliki oleh kelas dan karenanya memecah dokumen / view architecture.

Selain itu, sepertinya tidak efisien misalnya pernyataan SELECT hanya boleh memilih apa yang diperlukan, tetapi keberadaan variabel anggota dalam Faktur tampaknya menyiratkan "data yang dijamin".

Tidak tahu apakah saya menjelaskan pertanyaan dengan jelas, Apa saja pendekatan terbaik lain untuk arsitektur / pola desain / apa-itu-dikenal-sebagai?

Terima kasih atas sarannya

database

— Jake
sumber

Jawaban:

Yah saya kira Anda bisa menggunakan ORM.

Tapi sungguh, desain database TIDAK harus mengikuti prinsip-prinsip OOP, itu harus mengikuti prinsip-prinsip desain database seperti normalisasi. Dan itu harus dirancang pada basis data bukan dalam aplikasi. Dan aturan integritas data harus ditegakkan di tingkat basis data bukan oleh aplikasi.

Saya akan menyarankan Anda membaca beberapa buku desain database dan, kemudian, membaca tentang penyetelan kinerja database pilihan Anda.

— HLGEM
sumber

+1 karena tidak semuanya harus OOP (bahkan jika beberapa ORM cukup bagus!)

— Javier

O / RM itu bagus, tetapi menggunakannya tidak berarti Anda tidak dapat memenuhi desain database yang baik.

— BlackICE

@ David, saya setuju itu benar di tangan seseorang yang tahu apa yang dia lakukan. Dan saya menyarankan dia melihat ORM, tapi sungguh jika Anda tidak tahu desain database terlebih dahulu, ORM adalah alat yang berbahaya.

— HLGEM

Itu poin yang baik bahwa aturan integritas data dapat ditegakkan di tingkat basis data. Namun, kadang-kadang masuk akal untuk memasukkan beberapa aturan (seperti 'proyek harus selalu mengandung lebih dari 5 anggota tim') dalam aplikasi jika aturan dapat berubah, dan hanya aplikasi yang akan mengubah data.

— Jon Onstott

Aplikasi ini hampir tidak pernah menjadi satu-satunya hal yang memodifikasi data. Aturan bisnis yang tidak dimasukkan ke dalam basis data cenderung sangat mudah dilanggar ketika seseorang perlu melakukan perubahan cepat ke sejumlah besar data untuk mendukung beberapa perbaikan data.

— HLGEM

Saya tidak dapat menemukan struktur yang melengkapi pendekatan OOP yang merangkum implementasi database

Sepertinya Anda menggambarkan ketidakcocokan impedansi Object-relational .

Ada beberapa hal yang seharusnya dapat menyelesaikan OODBMS ini, alat ORM, sejumlah alat akses data.

Saya pikir kenyataan bahwa ada begitu banyak solusi membuat saya percaya bahwa One True Solution ™ tidak ada.

Jadi, Anda dapat memilih arah mana pun yang Anda sukai dengan aman dalam pengetahuan bahwa beberapa orang akan membencinya dan beberapa akan menyukainya.

— Conrad Frix
sumber

Sepertinya itu, dengan cara yang lebih keras.

— Jake

Jika Anda tidak ingin menggunakan pembungkus ORM, gunakan database yang mendukung penyimpanan gaya OOP seperti MongoDB .

MongoDB (dari "hu mongo kita") adalah cross-platform dokumen database berorientasi sistem. Digolongkan sebagai basis data " NoSQL ", MongoDB menghindari struktur basis data relasional berbasis tabel tradisional yang mendukung dokumen mirip JSON dengan skema dinamis (MongoDB memanggil format BSON ), menjadikan integrasi data dalam jenis aplikasi tertentu lebih mudah dan lebih cepat. ..

— Josh K.
sumber