In che modo le persone creano database riutilizzabili che possono essere utilizzati per molti prodotti?In che modo le persone creano database riutilizzabili?
Ad esempio, se abbiamo un database progettato per una scuola ... Può essere facilmente modificato per essere assegnato a un college?
Qual è il modo di creare un database che può essere utilizzato come prodotto per dare una soluzione a molti clienti con la codifica solo una volta?
Grazie
Un'applicazione come questa richiederebbe un modello di dati abbastanza complesso per tenere conto dei requisiti. Diversi tipi di scuole avrebbero requisiti diversi. Un'università potrebbe consentire di aggiungere o abbandonare corsi, ma in genere una scuola elementare no. Un'università deve programmare corsi nelle stanze, mentre una scuola elementare deve mettere gli studenti in gradi e dividere i voti in aule in base allo spazio disponibile e agli insegnanti.
Il progetto deve prendere in considerazione tutti i requisiti che è previsto risolvere e quindi implementare quelli. Più generico fai il programma più difficile è soddisfare i tuoi clienti. La domanda dice "scrivi il codice una volta". Se vuoi scrivere un singolo programma che risolva i bisogni di ogni scuola, avrà bisogno di centinaia di funzionalità; in alcuni casi alcune scuole richiedono una funzione opposta da un'altra scuola; per esempio alcune scuole dovranno imporre un insegnante per materia o classe, mentre un'altra scuola potrebbe richiedere più insegnanti. Maggiore è il numero di requisiti che ti aspetti di soddisfare, più complessa diventa l'applicazione.
Nelle applicazioni industriali tendono ad essere scritte in modo che possano essere estese; viene fornito un set di funzionalità di base, ma l'applicazione è destinata a essere modificata e personalizzata per un determinato cliente. Ciò rende più facile lo sviluppo perché non è necessario anticipare ogni esigenza; infatti non avrai bisogno di anticipare molte esigenze finché non avrai un cliente con queste esigenze. Ma con "personalizzazione" non si scrive codice solo una volta.
Il passaggio più importante è quello di creare un modello di dati sufficientemente flessibile da estendersi in seguito, ma non è così flessibile da non poter essere sviluppato. La parte più difficile è di solito correggere la cardinalità delle relazioni. Ad esempio, potresti dire che una classe ha un insegnante. Poi, quando si scopre che una classe ha bisogno di due insegnanti, devi riscrivere un sacco di codice e sistemare molti dati. Questi tipi di modifiche sono fastidiosi e richiedono molto tempo. Tuttavia, alla fine puoi sempre correggere gli errori con un tempo di programmazione sufficiente.
Non c'è un semplice proiettile d'argento per questo. Hai solo bisogno di mantenere il tuo database design abbastanza generico, ma cerca di evitare un'eccessiva generalizzazione in quanto di solito porta a incubi nella manutenzione e altre insidie.
Con l'esperienza, inizierai ad apprezzare un perfetto equilibrio tra generalizzato e specializzato. Questa è la chiave per un design comprensibile e riutilizzabile di codice/database.
il miglior consiglio che posso dare è quello di costruire al minimo comune denominatore ....
Quindi .... Codice come un progetto orientato verso strutture di istruzione :-)
Trascorrere del tempo a pensare sul tipo di dati che desideri archiviare, estrapolarli per renderli estendibili e quindi costruire di conseguenza il tuo database. Non so se riusciate a riutilizzare perfettamente il modo in cui potete dal codice, ma potete costruire una struttura di database (dove dovete ancora modificare i singoli componenti) che è riutilizzabile se pianificate in anticipo.
La risposta è trovare sweet spot di abstraction.
lol @ collegamento 'sweet spot' – mpen
Per la gente ESL per chi potrebbe trovare il termine dispari –
Dipende dalle vostre esigenze. Per esempio, molte molte basi di dati per le imprese di prodotti a base utilizzano un formato che comprende:
Nella tua situazione si potrebbe hanno
Questo formato generale tabella potrebbe essere riutilizzato in molte applicazioni.
È tutto nel design. In molti casi (se non la maggior parte), i database avranno bisogno di un certo livello di personalizzazione per le singole istituzioni; ma i database generalizzati possono fornire un livello base di funzionalità. È possibile progettare qualcosa che sia abbastanza generale per servire molti bisogni fondamentali; ma il problema è che la generalità del design tende a condurre ad alta complessità. Ad esempio, è possibile progettare il database in modo che sia basato sui dati per un ampio insieme di potenziali esigenze degli utenti; ma di solito, è solo meglio personalizzare lo schema in base alle esigenze individuali dell'istituzione.
Ci sono significativi compromessi coinvolti nella progettazione di una situazione di riusabilità; di solito coinvolgono tempo e complessità; cioè, è più facile progettare qualcosa che NON sia riutilizzabile; e di solito, il tempo addizionale richiesto per realizzare il progetto generale e usarlo non vale la pena.
Trova il giusto equilibrio di generalità e specificità nella progettazione del tuo database in modo che l'applicazione che crei intorno a esso risolva abbastanza problemi nei mercati di destinazione che tutti compreranno.
Di solito, quando le persone lo fanno, hanno più clienti nello stesso settore. Quindi, se sei uno sviluppatore web di e-commerce, allora avrai a disposizione gli stessi prodotti, ordini, dettagli del tipo di scenario della tabella più e più volte. Quando ciò accade, è un gioco da ragazzi creare un database iniziale.
E se si sta andando a percorrere questa rotta, è necessario anche mantenere gli script di aggiornamento tra ogni nuova versione che si effettua in modo da poter andare più facilmente indietro e aggiornare più clienti. –
Ogni cliente utilizzerà tutte le funzionalità o sta cercando di creare un prodotto adatto a tutte le dimensioni? Ho sempre riscontrato che il tempo aggiuntivo dedicato alla pianificazione e alla modifica di un database per adattarsi a una particolare applicazione si ripaga in futuro. È molto più facile lavorare con una struttura di database concisa rispetto a quella in cui si è tentato di tenere conto di ogni possibilità.
Se si dispone di un database simile o di un modello, di solito utilizzo uno strumento di modellazione di database come this per modificarlo e quindi utilizzare la funzionalità di generazione SQL (in caricamento/salvataggio) per creare il database effettivo.
Un altro trucco che ho rilevato di recente che mi ha risparmiato un sacco di tempo è quello di salvare l'SQL utilizzato per generare il database come script. Se voglio impostare un nuovo database, apporto tutte le modifiche al codice sorgente, quindi carico la pagina. Ad esempio, se volessi generare una nuova tabella clienti, carico http://localhost/load.php?generate=customer.
Spero che aiuti!
Primo passo, parla con una vasta gamma di potenziali clienti e scopri quali sono i loro bisogni, cosa stanno attualmente utilizzando e cosa desiderano fare i loro prodotti attuali. Spendi 10 volte tanto a questo come pensi di aver bisogno in questo momento. Disegna su carta una potenziale GUI e invita le persone che intervisti a guardare i disegni e a dare suggerimenti. Se possibile, assumere alcune persone del settore come analisti aziendali per aiutare con questo passaggio. Chiedi informazioni sui requisiti legali. Alcune industrie hanno un sacco di problemi di complicanze legali e altre no. Qualunque cosa sia collegata in qualche modo al mondo medico e tu dovrai ricercare e comprendere appieno i requisiti HIPPA, per esempio.
Progettare la struttura del database e una GUI per far sì che alcuni utenti reali giochino con esso. Refactor basato su quello che dicono (è incredibile quante cose gli utenti lasciano fuori dalle richieste che raccolgono a cui non pensano fino a che non si trovano di fronte a una GUI reale).
Pensa a ciò che deve essere comune a tutti i potenziali clienti e dove potresti aver bisogno di personalizzazione - le tue interviste dovrebbero guidarti qui. Decidi come gestire la personalizzazione. O anche se lo permetteresti. Questo può dipendere molto dal settore e dal livello di standard delle loro pratiche.
Se si tratta di un software box, spesso il progetto include una tabella con campi personalizzabili che possono essere aggiunti a maschere e report dall'utente.
In una soluzione basata sul Web, spesso ogni utente che desidera la personalizzazione può disporre di un proprio database in cui sono archiviate le informazioni personalizzate (e un database centrale stand-by per le cose non personalizzabili) ei programmatori apportano le modifiche in base alle richieste dei client . Se segui questa strada, la seconda volta che esegui una personalizzazione similare per un secondo cliente, valuta se è necessario un refactoring per rendere questa una nuova funzionalità del software disponibile per tutti. Non è necessario scrivere 17 rapporti di presenza personalizzati che variano solo di uno o due campi quando il cliente può avere meno denaro con un rapporto standard.
Nel modello Web, è anche possibile creare un gruppo di moduli e fare in modo che i client selezionino e scelgano quale aggiungere alla propria soluzione personalizzata. Pagherebbero in base al numero e alla complessità dei moduli che scelgono. Quindi il cliente che vuole solo tre report standard pagherebbe meno del client che desidera tutti i 27. Quando viene suggerita una nuova personalizzazione, il client paga per lo sviluppo se il suggerimento non sembra applicabile per gli altri, ma il modulo è fatto in modo che anche altri possano comprarlo. Se altri lo comprano, il cliente originario che ha chiesto la modifica potrebbe ottenere una parte del denaro fino al pagamento dei costi di sviluppo. Potrebbero anche richiedere che qualcosa rimanga come un modulo personalizzato e pagare un prezzo molto più alto per questo lavoro. Abbiamo alcuni clienti che non vogliono nemmeno i loro dati sugli stessi server nella stessa posizione degli altri clienti. Inutile dire che applichiamo un enorme premio per fare qualcosa del genere.
La personalizzazione è costosa e può portare a molti più programmatori necessari. Considerare molto fortemente prima di andare al percorso di personalizzazione. Può davvero essere la cosa che vende la tua soluzione software, ma non si adatta bene. Non è male quando hai dieci clienti, ma quando ne hai un centinaio puoi perdere il controllo molto velocemente. È molto più difficile interrompere la personalizzazione dopo averla offerta, piuttosto che aggiungere la personalizzazione in seguito da una suite standard. Spesso la necessità di personalizzazione è più nell'organizzazione del reporting aziendale. Se è possibile creare un'interfaccia di reporting in cui le persone possano scegliere e scegliere quali informazioni desiderano e salvare i propri report personalizzati, è possibile gestire la maggior parte delle esigenze di personalizzazione nel proprio settore senza la necessità di una personalizzazione completa.
Potrebbe essere vero, se applicazione nello stesso dominio, in tal caso, l'applicazione si comporta come un prodotto per tutti ... –