Best practice: modelli di programmazione delle app del database

Finora ho scritto molte app web di database (MySQL) ma penso sempre che la mia struttura sia un po 'goffa. Voglio migliorare il modello di programmazione / progettazione che utilizzo, sperando in qualche consiglio qui. In particolare, non riesco a trovare una struttura che integri un approccio OOP che incapsuli l'implementazione del database (schema). io

Penso che la mia domanda possa essere meglio spiegata con l'esempio. Ci sono 2 approcci che uso ora dicono che ho un oggetto / classe Invoice:

il primo è usare le funzioni statiche dei membri

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);
};

Il secondo approccio consiste nel mettere ogni cosa in un oggetto database:

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

Trovo che in entrambi i modi le funzioni del membro (SQL) siano molto inseparabili dalla "vista", in quanto la "vista" determina ciò che le classi devono avere e quindi sembra infrangere l'architettura documento / vista.

Inoltre, sembra in qualche modo inefficiente, ad esempio un'istruzione SELECT dovrebbe selezionare solo ciò che è necessario, ma la presenza di variabili membro in Fattura sembra implicare "dati garantiti".

Non so se ho spiegato chiaramente la domanda, quali sono alcuni altri migliori approcci a questa architettura / modello di progettazione / che cosa è noto?

Grazie per i consigli

database

— Jake
fonte

Risposte:

Beh, suppongo che potresti usare un ORM.

Ma in realtà, la progettazione del database NON dovrebbe seguire i principi OOP, dovrebbe seguire i principi della progettazione del database come la normalizzazione. E dovrebbe essere progettato nel database non nell'applicazione. E le regole di integrità dei dati dovrebbero essere applicate a livello di database non dall'applicazione.

Ti suggerirei di leggere alcuni libri di progettazione di database e, quindi, di leggere le prestazioni ottimizzando il database di tua scelta.

— HLGEM
fonte

+1 per non tutto deve essere OOP (anche se alcuni ORM sono abbastanza carini!)

— Javier

Gli O / RM sono belli, ma usarli non significa che non puoi conformarti a un buon design del database.

— BlackICE,

@ David, sono d'accordo che sia vero nelle mani di qualcuno che sa cosa sta facendo. E gli ho suggerito di guardare un ORM, ma davvero se non si conosce prima la progettazione del database, un ORM è uno strumento pericoloso.

— HLGEM,

Questo è un buon punto per cui le regole di integrità dei dati possono essere applicate a livello di database. Tuttavia, a volte ha senso inserire alcune regole (come "progetto deve contenere sempre più di 5 membri del team") nell'applicazione se le regole sono soggette a modifiche e solo l'applicazione modificherà i dati.

— Jon Onstott,

L'applicazione non è quasi mai l'unica cosa che modifica i dati. Le regole aziendali non inserite nel database tendono a essere violate molto facilmente quando qualcuno deve apportare una rapida modifica a una grande porzione di dati per supportare alcune correzioni dei dati.

— HLGEM,

Non riesco a trovare una struttura che integri un approccio OOP che incapsuli l'implementazione del database

Sembra che tu stia descrivendo la mancata corrispondenza dell'impedenza relazionale Oggetto .

Ci sono molte cose che dovrebbero risolvere questo OODBMS, strumenti ORM, una miriade di strumenti di accesso ai dati.

Penso che il fatto che ci siano così tante soluzioni mi porta a credere che One True Solution ™ non esista.

Quindi puoi scegliere qualsiasi direzione ti piace sapere che alcune persone lo odieranno e altri lo adoreranno.

— Conrad Frix
fonte

Sembra che lo sia, in un modo più rigoroso.

— Jake,

Se non si desidera utilizzare un wrapper ORM, utilizzare un database che supporti l'archiviazione in stile OOP come MongoDB .

MongoDB (da "hu Mongo noi") è un cross-platform database di documenti orientati al sistema. Classificato come un database " NoSQL ", MongoDB evita la tradizionale struttura di database relazionale basata su tabelle a favore di documenti simili a JSON con schemi dinamici (MongoDB chiama il formato BSON ), rendendo l'integrazione dei dati in determinati tipi di applicazioni più semplice e veloce. ..

— Josh K
fonte