Il problema più grande che avrai sarà con i database. All'interno dei database relazionali, ci sono alcune differenze dialettiche tra loro (cose che postgres fa diversamente da mysql o oracle) - diverse funzioni, diversi tipi di colonne. Ciò renderà difficile la scrittura della query corretta e la creazione dello schema del database corretto.

Con Hibernate (stack Java), è possibile inoltrare il database al tecnico. Si creano gli oggetti e il livello ORM crea il database corrispondente. Detto questo, questo significa che tutto ciò che fai è attraverso l'ORM. (Penso che ci sia una cosa corrispondente in Ruby da qualche parte, non che mi raccomando rubino).

Aggiungere "qualsiasi database" a ciò che include cose come Mongo significa che l'ORM non lo fa più. Anche il DBI di Perl non ha uno strato DBD corrispondente per Mongo - il paradigma per il database è troppo diverso.

potresti aggiungere un altro layer davanti all'ORM per avere il tuo layer ORM con i driver del database codificati a mano per Mongo, Couch, NoSQL Flavor della settimana, ecc ... Ma ora stai codificando ogni strato ancora e ancora.

Credo che fondamentalmente il tuo cliente non capisca la natura di ciò che sta chiedendo. Essere in grado di eseguire ovunque senza controllo su ciò che è installato, o anche il database che esegue il backbending è un compito impossibile.

Potresti prendere in considerazione l'idea di lanciare una distribuzione di una macchina virtuale. Questo ha l'intero stack che si desidera / richiede su di esso in un pacchetto che viene poi distribuito su un altro computer che esegue la VM. Metti il database, il server web, il server delle applicazioni, ecc. In quella VM e quella VM viene distribuita.

Ovunque possano eseguire una macchina virtuale (ovunque), lo stack può essere distribuito. La sua unica cosa è necessaria sul computer di destinazione: il lettore di macchine virtuali.

Qui ci sono due problemi:

• Far capire al cliente cosa è possibile e cosa no. Soprattutto, lo sviluppo non può essere accelerato arbitrariamente gettandogli denaro o manodopera. Sarebbe meglio identificare le caratteristiche di priorità che devono essere presenti nella prima versione e le funzionalità opzionali che possono essere aggiunte in seguito. Ovviamente il cliente non può avere tutto in una volta.

• Il lato tecnologico delle cose.

I diversi database potrebbero essere nascosti dietro un ORM, oppure potresti ricorrere a qualcosa che funzionerà ovunque (sì, sto suggerendo SQLite - qui è meno pazzo di quello che vuole il tuo cliente). La tua webapp può essere eseguita sul proprio server, che viene semplicemente inoltrato attraverso il server web di implementazione richiesto, che in ogni caso è un'architettura sana. Tuttavia, devi in qualche modo eseguire la tua webapp: Avrai bisogno di una JVM se usi Java, o l'interprete perl se scegli Perl, o una VM Python se segui questa strada. Questi non sono sempre un dato, ad es. Su Windows. Quindi hai già una dipendenza .

Ora che la porta è aperta, possiamo aggiungere ulteriori dipendenze: non importa quante dipendenze hai, solo se i client del client dovranno installare manualmente queste dipendenze. Fornire quindi script di installazione sarebbe quindi preferibile al tentativo di adattarsi a qualsiasi ambiente.

1) È possibile progettare il nucleo della logica dell'applicazione senza tenere conto di un framework, essenzialmente progettando il proprio framework. L'uso di CGI per Perl o C sarà una buona base per la parte di back-end. Tuttavia, l'interfaccia del database richiede livelli di adattamento e shim.

2) Sarà necessario sviluppare un software adattatore per ciascun database a cui si desidera connettersi. Dato che MongoDB e MySQL sono animali completamente diversi, dovrai mirare a un minimo comune denominatore e fare la differenza nella tua applicazione.

3) Sfortunatamente, non sarai in grado di soddisfare i requisiti in 4 mesi. Lo sviluppo e il collaudo delle interfacce nei singoli database richiederanno notevoli sforzi di verifica. Se si utilizza il DBI Perl, ad esempio, sarà possibile indirizzare la maggior parte dei database SQL, richiedendo solo la personalizzazione per la generazione automatica delle chiavi primarie. Lo sviluppo di un equivalente per i database NoSQL richiederà un grande sforzo.

Per quanto riguarda il lancio di più soldi per il problema ... "Contrariamente alla credenza popolare, nove donne non possono consegnare un bambino in un mese."