Consiglio su struttura applicazione

martedì 31 marzo 2009 - 10.09

jampicoll Profilo | Junior Member

Ciao a tutti,
dovrei realizzare un applicazione web per l'inserimento di alcuni dati di utenti (tipo curriculum). Mi è sorto un dubbio riguardo la gestione delle esperienze lavorative.
Io vorrei fare una cosa carina, cioè creare un tasto aggiungi che ad ogni click fa comparire nella pagina un mini-form per l'inserimento dell'esperienza lavorativa.
Ammesso che riesca a fare questo il mio problema diventa poi la gestione dei dati nel database.
La regola indicherebbe di fare una tabella anagrafica con i dati dell'utente collegata ad una in cui sono presenti le esperienze.
In alternativa, ma molto sbagliato a livello di architettura, potrei fare un unica tabella con la possibilità di inserire un numero massimo di esperienze (esperienza1, esperienza2,....).
Da notare che il sistema dovrà prevedere anche dei strumenti di filtro e ricerca anche sul campo "esperienza lavorativa".

Il mio problema è:
siccome sono alle prime esperienze con questo ambiente di programmazione non vorrei incasinarmi in cose troppo difficili da fare. Se vado per la prima struttura (tabelle suddivise) credo di poter incontrare difficolta nelle operazioni di salvataggio e aggiornamento.
VI CHIEDO DI CONSIGLIARMI.

Grazie
Giampiero.

alx_81 Profilo | Guru

>Ciao a tutti,
Ciao

>La regola indicherebbe di fare una tabella anagrafica con i dati
>dell'utente collegata ad una in cui sono presenti le esperienze.
>In alternativa, ma molto sbagliato a livello di architettura,
>potrei fare un unica tabella con la possibilità di inserire un
>numero massimo di esperienze (esperienza1, esperienza2,....).
>Da notare che il sistema dovrà prevedere anche dei strumenti
>di filtro e ricerca anche sul campo "esperienza lavorativa".

>Il mio problema è:
>siccome sono alle prime esperienze con questo ambiente di programmazione
>non vorrei incasinarmi in cose troppo difficili da fare. Se vado
>per la prima struttura (tabelle suddivise) credo di poter incontrare
>difficolta nelle operazioni di salvataggio e aggiornamento.
>VI CHIEDO DI CONSIGLIARMI.
Non ti consiglierei mai una soluzione inutilmente denormalizzata e invece ti dire di seguire almeno le prime forme normali (http://it.wikipedia.org/wiki/Normalizzazione_del_database). E i motivi sono vari. Intanto, l'hai detto tu, i filtri. Se hai tanti campi "polmone" atti a contenere il massimo delle esperienze, la ricerca ti farà dannare, perchè chi vorrà utilizzare il filtro vorrà altresì potere navigare su tutto con una pesante OR sui campi.
Poi, In caso di visualizzazione delle esperienze, dovresti inventarti un algoritmo controllando anche (inutilmente se messe in verticale) quando le esperienze non sono più popolate. Poi, gli indici. se devi fare un indice su n campi e non sai nemmeno quanti di questi sono realmente popolati, di sicuro non avrai un indice efficace, in quanto non sei nemmeno sicuro su quali campi effettuerai la ricerca. Ed infine, pensa anche se raggiungi il massimo delle esperienze. E se te ne servono altre.. ti tocca aggiungere un campo, il che significa cambiare la struttura e di conseguenza anche l'applicazione. Poco produttivo direi.
No, mi dispiace, ma mi schero coi contrari della soluzione 2 .
Meglio fare un buon diagramma database che ti garantisce velocità, affidabilità e migliore lettura delle informazioni. In fondo, se devi gestire inserimenti, cancellazioni e aggiornamenti su più tabelle, avrai costruito Foreign Key di relazione e opportune stored procedure (o quant altro, dipende da che RDBMS utilizzerai) che ti gestiscano le chiamate. L'applicazione non ne risentirà per nulla. Anzi, trarrà solo vantaggi.

>Grazie
di nulla!

--

Alessandro Alpi | SQL Server MVP

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2024
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5