La mia app Web utilizza un numero di API di hosting fotografico. Quale sarebbe una progettazione efficace del database per archiviare i propri limiti?

1

Per un esempio , diciamo che sto usando Picasa , Flickr e 500px API e che ciascuno dei servizi presenta limitazioni su questi parametri semplificati:

  • spazio totale account
  • dimensioni del file individuali

Ho una tabella di database chiamata external_services dove memorizzo i dettagli di tali servizi, i miei token di accesso sviluppatore, ecc., e ho bisogno di fare riferimento ai limiti sopra indicati nella mia applicazione. Posso pensare ai seguenti modi per memorizzare tali informazioni:

1) Aggiungi colonne ad esso per mantenere le informazioni in linea.

+--------+-------+--------+-
| Name   | Space | File   | …
+--------+-------+--------+-
| Flickr | 1 TB  | 200 MB | …
+--------+-------+--------+-
| Picasa | 15 GB | 75 MB  | …
+--------+-------+--------+-
| 500 px | 60 GB | ?? MB  | …
+--------+-------+--------+-

2) In alternativa, mantieni una meta tabella separata chiamata external_services_details con una relazione uno-a-molti.

+--------+------------+--------+
| Name   | Parameter  | Value  |
+--------+------------+--------+
| Flickr | acct_space | 1 TB   |
+--------+------------+--------+
| Flickr | max_file   | 200 MB |
+--------+------------+--------+
| Picasa | acct_space | 15 GB  |
+--------+------------+--------+
| Picasa | max_file   | 75 MB  |
+--------+------------+--------+
| 500 px | acct_space | 15 GB  |
+--------+------------+--------+
| …      | …          | …      |

Il mio problema è Non posso dire la differenza tra questi due approcci in termini di entrambe le opzioni essendo a prova di futuro, voglio dire non posso prevedere uno scenario in cui fai la differenza Mi pentirò di sceglierne uno rispetto all'altro? Il motivo per cui lo chiedo è che sono certo che i programmatori migliori di me devono averlo affrontato prima e hanno imparato le loro lezioni, e che c'è già una risposta da qualche parte.

Ora, oltre a questo, ci sono anche limiti specifici di ciascuno dei servizi. Ad esempio, Flickr richiede che Le immagini non possono essere più di 31.25 volte più larghe di quanto siano alte , e nella sua Politica di utilizzo corretto, 500px limiti nuovi utenti per un massimo di 20 nuove fotografie / immagini per settimana .

Il mio pensiero è questo: se i requisiti differiscono, sembra che un modo migliore sarebbe archiviarli in una meta tabella, con un numero flessibile di righe collegate a ciascun servizio. Ma se inizio a incorporare questa logica nell'app, dovrò normalizzare i dati che ho comunque, cioè se Flickr limita il rapporto immagine, dovrei avere una risposta a quello per ciascuno dei servizi rimanenti, anche se non elencano questa limitazione, allora dovrei avere memorizzato lì o qualcosa del genere. Il tipo di mezzo che l'approccio alla tabella strutturata in realtà ha più senso qui, poiché impone quella struttura.

Quale sarebbe il modo efficace per gestirlo? C'è un nome per questo modello?

Potrei averlo chiesto su DBA , ma una parte di questa domanda si occupa di ottenere la giusta logica applicativa, e questo è il software design.

Mi spiace per il cattivo design del layout di tabella

Riferimenti . I valori nelle tabelle sopra sono reali, ho studiato. Se qualcuno finisce in questa pagina alla ricerca dei limiti effettivi, eccoli qui:

posta aexl 09.04.2016 - 14:57
fonte

1 risposta

2

Per ogni parametro per il quale la tua applicazione deve interpretare la semantica, l'opzione 1 è IMHO la migliore poiché è più semplice, più espressiva e l'ulteriore flessibilità della tua opzione 2 non ti offre un vantaggio, poiché quando più tardi introdurre nuovi parametri aggiuntivi necessari per cambiare la tua applicazione. Se alcuni servizi non hanno un limite specifico, imposta il valore su NULL, ovvero a cosa serve NULL.

L'opzione 2 ha senso solo quando è molto costoso cambiare la struttura del database in un secondo momento, molto più costoso cambiare l'applicazione e ci si aspetta un sacco di nuovi "parametri limite" che non si possono ancora prevedere.

La domanda più interessante è: cosa fare con le singole regole complesse che non possono essere facilmente codificate in una colonna di parametri. In pratica hai le seguenti opzioni:

  1. non li convalida affatto, basta mostrare un testo descrittivo all'utente per questi limiti. In questo caso, è sufficiente una colonna di testo aggiuntiva, contenente il testo. Questo potrebbe essere ok, ma può darti dei problemi quando l'applicazione deve essere localizzata.

  2. Convalidali con un codice di convalida non generico, specificamente scritto per il servizio (di solito utilizzerai il modello di strategia per questo). Questo caso non ha molto senso da implementare nel tuo database. Questo va bene quando vuoi supportare solo una piccola dimensione di API fotografiche e puoi fornire aggiornamenti facilmente e rapidamente per la tua applicazione quando le regole vengono modificate dal provider API. Potresti anche considerare di usarlo come approccio solo , senza il fastidio di una tabella del database.

  3. Rendi possibile memorizzare regole complesse nel DB, magari una colonna di testo "regola specifica", in cui puoi fornire una formula come height>0 AND width>0 AND width/height <1 . Questo potrebbe richiedere uno sforzo maggiore rispetto alle prime due alternative, dal momento che devi scrivere un interprete di formula, ma è sicuramente l'approccio più "a prova di futuro". Devi decidere da solo se vale la pena.

risposta data 09.04.2016 - 15:40
fonte

Leggi altre domande sui tag