sto chiedendo problemi? DB e gestione di record di articoli variabili

0

Penso che sia così semplice, ma sembra troppo facile e ovvio e perché nessuno lo ha suggerito 10 anni fa. E so che ci sono molte persone molto più brillanti di me nel mondo degli sviluppatori di software ...

Quindi mi è stato chiesto di fare un lavoro quick-n-dirty (2 giorni) per un'applicazione di una pagina web: raccogliere un modulo, recuperare e duplicare il modulo come testo e non formare elementi. Tutto via browser La pila di strumenti è limitata all'impostazione di base della LAMP e qualsiasi cosa i web ragazzi / ragazze possano spremere tramite jquery, ecc.

Nessun problema. Normalmente installerei una tabella db con un campo per ogni elemento catturato, tipi di dati appropriati, lunghezze, ecc. Analizziamo e disinfettiamo l'input, inseriamo in db con istruzioni preparate, ecc. Quindi recuperiamo e ri-visualizziamo tramite un modello e gettoni. Roba di base per CRUD, non avere a che fare con alcune web app che fanno già cose del genere, nessun problema.

Ma il problema è che la forma che deve essere compilata ha aree in cui più sottocartelle (quali scuole hanno frequentato - scuola, date, gradi se premiati - potrebbe essere una, potrebbero essere sette). E ci sono molte altre forme che potrebbero utilizzare lo stesso processo. E i ragazzi / ragazze del web vogliono essere in grado di farlo senza che io sia così coinvolto (sono d'accordo: la programmazione è solo il 30% circa del mio lavoro).

Quindi penso che ogni modulo abbia qualcosa in comune con tutti gli altri: nome, cognome e indirizzo email. Qualcos'altro dopo che è in aria, l'unica garanzia è che nessun upload di file.

Se dovessi impostare un semplice script di elaborazione generico sottoposto a una tabella, presentato come

, chiederei dei problemi
pk | webform name | first name | last name | email address | submission timestamp | complete form as JSON string

??

Fare qualcosa del genere sembra così semplice e banale ... Devo chiedermi ...

Configura l'inserto e recupera quasi un'API per i ragazzi / ragazze del web per catturare i dati, semplicemente presentandoli con la stringa JSON. Non preoccuparti di una seconda / terza / nona tabella con le relazioni di ritorno al materiale demografico, dovendo creare database e tabelle per ognuno individualmente, ecc.

Mi sto ponendo dei problemi per l'archiviazione dei dati in questo modo? Sembra troppo facile. Cosa mi manca?

EDIT - il seguito

E ora, pochi mesi dopo ... Sono andato con la memorizzazione della stringa JSON per rappresentare il modulo completo, ma solo come una soluzione rapida e sporca. Ricreare il modulo con il contenuto degli utenti per le modifiche è banale e funziona bene.

Sfortunatamente, sono state bloccate su versioni molto vecchie del software a causa di ITS (fanno infrastruttura e roba ERP, il mio gruppo è separato e fa tutto il "normale" web) e cambiano qualcosa come PHP 5.6 o anche 7.x è disponibile il momento, e basta dimenticare MongoDB o qualsiasi altra roba lato server.

Sto lavorando con la gente del front end e sto cercando di trovare una soluzione reale, ma le cose sono in sospeso all'inizio del semestre (tutti noi andiamo a nutz a fare altre cose per un mese) quindi qualsiasi altra soluzione presentata sarebbe ottima.

    
posta ivanivan 20.06.2018 - 03:57
fonte

2 risposte

1

Dipende molto da come intendi utilizzare i dati.

  • I tuoi dati sembrano strutturati
  • Alcuni campi sono costituiti da classi correlate o sottoclassi (scuole, gradi)

Se i dati vengono utilizzati in modo diverso dalla visualizzazione, potrebbe non valere la pena di creare debito tecnico dal primo giorno. Prendi in considerazione l'upgrade dello stack, la normalizzazione dei dati e il tempo necessario per prendere decisioni appropriate in merito al design. Inizia descrivendo funzionalmente ciò che questo modulo è esattamente (think domain object).

Detto questo, ci sono alcune opzioni per hackerarlo davvero:

  • Memorizzazione dei campi sconosciuti come JSON nel tipo di dati JSON (MySQL > = 5.7.8) o Tipo di TESTO
  • Firmare un database di documenti come MongoDB destinato a questo tipo di archiviazione.
risposta data 09.07.2018 - 17:45
fonte
1

Se ho capito bene il problema, il modo standard per gestire questo tipo di cose in un DB relazionale è creare una tabella con 4 colonne (o più, se necessario): primary key , parent key , field name , field value . Dove parent key è una chiave esterna del record principale e field name è una colonna tipo stringa di dimensioni moderate e field value è una colonna tipo stringa di grandi dimensioni.

Quindi ogni record creato avrà i campi modulo standard e le righe 0-n nella tabella subordinata per i campi non standard.

Memorizzando i dati aggiuntivi come una grande stringa è fattibile ma qualcuno (ad esempio il cliente) dovrà tenere traccia del formato del campo. Inevitabilmente, il cliente si evolverà e i dati in questo campo varieranno nel tempo. È anche più difficile fare query su questo tipo di campo che se lo si interrompe. In sostanza, si perde molto del valore di un DB relazionale inserendo dati non strutturati. Se non hai davvero bisogno delle funzionalità relazionali, allora potrebbe essere il momento di prendere in considerazione la possibilità di passare a un meccanismo di archiviazione più semplice.

    
risposta data 09.07.2018 - 21:46
fonte

Leggi altre domande sui tag