Sono nel bel mezzo della progettazione di una classe di accesso al database di prossima generazione per uno dei programmi che sto costruendo. Utilizziamo esclusivamente PostgreSQL.
Il nostro attuale approccio è procedurale (largamente ispirato a credere o meno ai servizi web RESTful, ma prestando attenzione anche alla scoperta). Il database definisce (piuttosto vagamente) un'API che l'applicazione scopre. L'API è progettata per essere sia prontamente utile sia leggibile per computer e DBA.
Puoi leggere il nostro approccio attuale al link ma il punto fondamentale è che cerchiamo names solo di dati e generiamo chiamate procedurali che sono facilmente mappate ai metodi. Le nostre classi Perl supportano un'interfaccia di chiamata come:
$recon_report->exec_method({ funcname => 'cash_recon__approve' });
Ciò riutilizzerebbe le proprietà dell'oggetto per riempire gli argomenti previsti per cash_recon. Ciò consente di modificare l'API in misura ridotta senza interrompere il contratto di base con l'applicazione e quindi consente di evitare il peggiore dei problemi di stored procedure. Quanto sopra potrebbe generare una query sql come:
SELECT * FROM cash_recon__approve(134);
La definizione della funzione in PostgreSQL sarà simile a:
CREATE OR REPLACE FUNCTION cash_recon__approve(in_id int) returns ...
Uno dei grossi problemi con questo approccio è che è molto necessario gestire un gran numero di nomi di funzioni in questo modo, quindi sto cercando un'interfaccia più simile a un oggetto attorno al database. Attualmente lo gestiamo usando i caratteri di sottolineatura doppio, ma questo crea tanti problemi quanti ne risolve. È leggermente meglio che usare caratteri non standard e richiedere che ogni nome di funzione sia quotato quando un dba lo digita o in caso di test.
La nuova interfaccia che sto guardando sarebbe diversa. Invece di identificare il tipo dalla parte prima del carattere di sottolineatura, sarebbe il tipo utilizzato dal primo argomento. L'equivalente di quanto sopra sarebbe il più fastidioso aspetto:
SELECT * FROM approve('(35,65,1111111,f,f,2011-10-06,"2011-10-07 13:11:24.324195",186,chris,f,,,,f)'::cash_recon);
La definizione della funzione qui apparirebbe simile a:
CREATE OR REPLACE FUNCTION approve(obj cash_recon) RETURNS ....
Tale interfaccia sarebbe anche rilevabile ma si baserebbe sulla scoperta. Non è così probabile che le persone possano leggere la chiamata e capire esattamente cosa ha fatto subito. Il vantaggio principale è che consentirebbe il passaggio di strutture dati complesse, e ciò sarebbe necessario per le procedure che prevedono di essere in grado di determinare se una transazione è bilanciata prima di scriverla nel database, quindi ci sono casi in cui ciò è chiaramente preferibile. Richiede però che i casi di test debbano essere generati dinamicamente dal database. I casi di test scritti manualmente potrebbero essere piuttosto fragili.
Quindi l'esempio sopra mi sembra un caso in cui l'interfaccia della stored procedure esistente è probabilmente preferibile, mentre la pubblicazione di una voce di diario mi sembra una soluzione in cui l'approccio in fase di sviluppo è significativamente preferibile.
Quindi la mia prima domanda è, dato che queste due API hanno diversi punti di forza e di debolezza, alza qualsiasi bandiera rossa per supportare entrambi e presuppone che le stored procedure possano essere scritte su entrambe le specifiche? O è generalmente meglio avere una specifica più piccola con un solo approccio API supportato. In altre parole, la vecchia API dovrebbe essere deprecata o utilizzata insieme a quella nuova? Mi sto appoggiando a quest'ultimo, ma vorrei ricevere un feedback.
La seconda domanda è, supponendo che supportiamo entrambi, è meglio scoprire la forma dell'API in fase di esecuzione o richiedere una chiamata diversa per il vecchio rispetto al nuovo stile? Mi sto appoggiando qui alla scoperta perché consente di riscrivere le funzioni nel db e, se necessario, di rimanere compatibili con le chiamate.