Raggruppamento e modifica della struttura dei dati: attività mutevoli con i dati del database

0

La scrittura di alcuni servizi su un sistema su cui sto lavorando ha sollevato alcune domande su come fornire i dati formattati per il client (viste o app per dispositivi mobili). Fondamentalmente, il mio dubbio nasce ogni volta che ho bisogno di fornire dati o dati raggruppati che devono essere modificati dopo la query.

Userò come esempio una relazione Has Many Through:

countries
    id - integer
    name - string

users
    id - integer
    country_id - integer
    name - string

posts
    id - integer
    user_id - integer
    title - string

Sto usando l'esempio di base che usa il framework Laravel. Ma la mia struttura è un po 'più complessa. Ad ogni modo, proverò a mettere insieme uno scenario basato su questa struttura.

Supponiamo che, per regola aziendale, ogni volta che devo elencare i post, essi dovranno essere raggruppati per paesi. Pertanto, ritengo che, in quanto requisito della regola aziendale, ogni volta che i miei clienti richiedono post, il servizio post deve fornire i dati raggruppati.

Nel caso di cui sopra è molto semplice, nel caso reale devo raggruppare ulteriormente, modificare alcune informazioni dei campi di ogni record del paese e dei loro rispettivi post. E a questo punto, mi chiedo sempre quale sia il modo "migliore" per realizzare questa formattazione dei dati.

  • Ho lavorato su sistemi che i campi che dovevano essere modificati, erano già stati risolti attraverso una vista nel database che creava le relazioni necessarie e forniva già tutto pronto. Lasciando che la programmazione risolva il raggruppamento dei dati e le possibili modifiche delle strutture.
  • In altri sistemi, abbiamo utilizzato un potente ORM che poteva fare grandi join interiori mantenendo le prestazioni (che non è il caso di tutte le ORM).
  • E in altri casi, a causa della lentezza generata dal framework ORM che abbiamo usato, abbiamo fatto diverse piccole query e poi raggruppato e modificato i dati a livello di codice in strutture ripetitive.

Prima domanda: c'è un modo GIUSTO per fare questo tipo di lavoro?

Seconda domanda: se si tratta di una domanda CASE (che ritengo possa essere), se in qualsiasi progetto creo diversi modi per raggruppare i dati, creerò un codice errato?

Terza domanda: se per caso decido di eseguire i raggruppamenti di dati a livello di codice, creare una query nel database e quindi modificare lo stato di tale risultato nel codice, sarebbe una cattiva pratica?

A volte penso che le viste nel database siano sempre le migliori soluzioni. Ma nel mio caso reale, ci sono quasi 120 tavoli. E ho già un sacco di codice che si occupa di grandi strutture di relazione a livello di programmazione da quelle tabelle. Penso che iniziare a scrivere viste ora creerebbe un disordine da dove si trova la regola aziendale.

Che ne pensi di tutti questi casi?

Grazie in anticipo!

    
posta Rafael Soufraz 16.06.2017 - 00:46
fonte

1 risposta

1

Quindi il requisito aziendale è ad esempio quello di visualizzare tutti i post raggruppati sotto le intestazioni dei paesi.

Vorrei fare sia:

  • 1 seleziona tutti i Paesi con post
  • 2 seleziona tutti gli utenti con i post ordinati per paese
  • 3 seleziona tutti i post ordinati per utente e paese

crea il display in codice. a causa dell'ordinamento dovrebbe essere richiesto un solo passaggio.

o

  • 1 seleziona tutti i Paesi con post
  • 2 loop through, selezionando tutti i post per ogni paese a sua volta

Ciò richiede più chiamate db ma evita di restituire i dati dell'utente.

Queste non sono le query più efficienti per l'attività specifica. Ma quello che sto cercando di evitare con questi approcci è

  • Creazione di nuovi oggetti "composti" aggiungendo campi aggiuntivi da altre tabelle. es. CountryId da pubblicare.

Questa è una strada pericolosa da percorrere perché ogni chiamata di progettazione dell'interfaccia utente implicherà la creazione di nuovi oggetti "postWithX" o l'aggiunta di campi aggiuntivi fino a che l'oggetto post non contiene tutti i dati nel mondo.

  • Creazione di query eccessivamente specifiche che sono utili solo per una singola attività.

Voglio poter riutilizzare le stesse chiamate GetPostsByX, GetUserByY su molte UI e non progettare nuove query SQL solo perché il carattere cambia. Cerca di evitare GetCountriesByUserLastNameSortedByDoB se possibile.

  • Creazione di oggetti complessi che includeranno più informazioni del necessario e saranno lenti da costruire da molte tabelle. cioè Country.Users[0].Posts

Questo genere di cose renderà molto più lento il popolamento del selettore del menu a discesa Paese su qualche altra interfaccia utente. Finirai per creare versioni "Lite" di tutti i tuoi oggetti

In generale, ritengo sia meglio provare a mantenere gli oggetti come se fossero nel DB

  • Non aggiungere o rimuovere campi o relazioni,
  • Non costruire oggetti complessi con figli di bambini di bambini. Basta includere l'id genitore di collegamento come nella tabella
risposta data 16.06.2017 - 02:39
fonte

Leggi altre domande sui tag