Cosa fare quando la lampadina si accende a metà e lo sviluppo web non progredisce: imparare da Ulisse, aggirare gli scogli per la NORMALIZZAZIONE

Scacco e poi Matto!

Cosa fare quando la lampadina si accende a metà e lo sviluppo web non progredisce: imparare da Ulisse, aggirare gli scogli per la NORMALIZZAZIONE

Ottobre 21, 2020 codeigniter 0

Chi si intende di poeti omerici sa che Ulisse sbattè la testa contro gli scogli tornando a casa e non riusciva ad approdare. Da qui la brillante idea di aggirare l’ostacolo insormontabile per cercare pareti meno ostili. I problemi che può incontrare lo sviluppatore sono molteplici, alcuni che si risolvono subito , altri che richiedono approfondimenti nelle dinamiche e altri ancora come i miei con Codeigniter dovuti alla carenza di informazione in questa prima fase di sviluppo (per esempio cosa sono i SEGMENT? Posso utilizzarli per caricare i parametri da integrare nelle mie query di atterraggio quando cerco di trasferire dei valori da una pagina all’ altra?). Facendo seguito a https://www.farwebdesign.com/wp/cera-una-volta-il-west-o-cera-di-mezzo-solo-un-parametro-lo-chiamavano-trinita-o-era-solo-codeigniter-con-la-sua-logica-model-view-controller-ad-avere-lesclusiva-indagini-sulle-d/ vediamo come è progredita la questione del passaggio dei parametri che in procedurale é semplice e qui é un mistero. Come testimonia l’immagine in cui in basso si evince il passaggio effettivo via GET (che però Codeigniter non supporta) dopo aver modificato il codice critico all’ altezza del link che deve trasferire l’informazione dopo il punto interrogatico con:

<?php
$id_regista=$row->id_regista;
//echo $id;
echo “<h5><a href=’index.php/western/regista?id_regista=$id_regista’>.$row->regia</a></h5>”;
?>

e verificato che tutti funziona grazie anche a semplici istruzioni che stampano a video il VALORE della variabile $id_regista, abbiamo detto ok aqdesso qui é tutto a posto, ma occorre modificare il MODEL in un certo modo, cosa del tutto riuscita del resto per verificare che la stampa della variabile passando dal punto A al punto Z non si perda per strada e sulla pagina ci finisce, ma purtroppo non finisce dentro la query per estrapolare i dati per cui la conclusione parziale dell’ enigma é che secondo lo sviluppatore è tutto ok ma non é questa la tecnica MVC che Codeigniter usa per fare questa operazione. Quindi quando le cose non progrediscono e non ci sono idee comunque l’applicativo ha un potenziale di sviluppo per crescere che non può essere arrestato anche perchè se non funziona in un modo il NEOFITA usando TECNICHE DI SPAGHETTI CODE può forzarne comunque l’uso pratico, ad esempio potrei semplicemente fare molte pagine diverse dove far transitare delle query senza usare il GET ma la prima regola del programmatore è quella di semplificare e rendere minimalista non creare groviglio di codice in eccesso! Comunque vediamo cosa si è fatto in alternativa. IL DATABASE AVEVA DEI PROBLEMI DI RIDONDANZA nel senso che i record con il nome dei registi si moltiplicavano per cui abbiamo pensato di creare una tabella esterna “registiwestern” che contiene al suo interno due campi, id_regista campo INT numerico SENZA INCREMENTO AUTOMATICO perché abbiamo necessità di etichettare ogni regista con un numero univoco in modo poi di fare in un futuro che verrà delle INNER dalle SELECT nel nostro MODEL Codeigniter e far scomparire il campo regia dalla tabella principale che propone dati in eccesso inutili. Poi abbiamo messo in ordine i registi e li abbiamo marcati con un riconoscimenti numerico univoco (id_regista) nella nuova tabella e anche nella vecchia. Fatto questo abbiamo armeggiato poi con la nuova struttura sul passaggio di parametri (senza successo) e alla fine abbiamo deciso di affrontare la questione dinamica della visibilità utente, nel senso che quando abbiamo ospiti sul nostro sito dobbiamo offrire sempre contenuti dinamici e frizzanti, mai la stessa vetrina statica. Questo problema della vivacità si può risolvere grazie a dei semplici <script> da mettere nei punti critici dove desideriamo mostrare i dati. Di fatto tutto ciò si risolve usando un semplice ARRAY che contiene tutte le frasi esplosive tratte da film cult e mescolate a funzione random offerte da JS per mescolare il mazzo. In particolare dentro i nostri div inseriamo:

<script language=”JavaScript”>
Aforisma = new Array()
Aforisma[0] = “Ognuno per sé e il diavolo per tutti”,
Aforisma[1] = “Non basta una corda a fare un impiccato”,
Aforisma[2] = “-Sia lodato Gesù Cristo, figliolo -Perché?”,
Aforisma[3] = “La fede può fare miracoli se la metti in una canna del fucile”,
Aforisma[4] = “Se questo Lucifero si fa vedere, ditegli di andare al diavolo”,
Aforisma[5] = “Se vuoi uccidere qualcuno devi mirare al cuore”,
Aforisma[6] = “A trovare un’ altra moglie si fa presto, ma una cavalla come quella non la trovo più”,
Aforisma[7] = “Chi ne ha accoppati quattro ci mette poco a fare cinque”,
Aforisma[7] = “Lavorare per essere pagati è umiliante… meglio rubare… c’è più emozione”
casuale = Math.random() * (Aforisma.length)
casuale = Math.floor(casuale)
document.write(Aforisma[casuale])
</script>

A questo punto abbiamo verificato che il lavoro (anche quando i big problem rimangono in sospeso) non manca mai, nel senso che tante sono le cose da fare per far crescere la propria applicazione e ovviamente molto importante risulta il processo di NORMALIZZAZIONE DEL PROPRIO DB. Per entrare nell’ accademico, carpendo dalla rete (MRW.IT):

il processo che evita la ridondanza dei dati e li ottimizza è detto normalizzazione, per ridondanza dei dati si intende la presenza di dati uguali nella stessa tabella, dati che potrebbero essere ottimizzati meglio se divisi in più tabelle (concetto di relazione o join) i cui campi fanno riferimento tra loro, avendo un database ottimizzato alla meglio e più snello.