[SQL SERVER 2008] Un po di chiarezza

giovedì 03 giugno 2010 - 22.45

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

TOPOAMORE Profilo | Expert

695 messaggi | Data Invio: gio 3 giu 2010 - 22:45

Salve a tutti,

volevo sapere il perche ogni volta che provo a fare una modifica nelle tabelle (gia esistenti) di sql server mi dice sempre che non e possibile e bisogna ricreare il tutto.

Premetto che ho impostato la voce changingtrackingenabled a true sul db.

Il problema nasce sopratutto quando non ho creato una chiave primaria a una tabella e successivamente devo inserirla. Li devo perforza ricreare la tabella e di conseguinza re-inserire i dati.

E' normale????

saluti

__.__.__.__.__.__

ASP 2.0 - VB 2008

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: ven 4 giu 2010 - 01:41

>Salve a tutti,
Ciao

>volevo sapere il perche ogni volta che provo a fare una modifica
>nelle tabelle (gia esistenti) di sql server mi dice sempre che
>non e possibile e bisogna ricreare il tutto.
>Il problema nasce sopratutto quando non ho creato una chiave
>primaria a una tabella e successivamente devo inserirla. Li devo
>perforza ricreare la tabella e di conseguinza re-inserire i dati.
>E' normale????
Che edizione di SQL Server? La 2008? Perchè da quell'edizione il designer di SSMS non ti permette i cambiamenti che impongono un drop della tabella.
Questo può essere facilmente bypassato andando a deselezionare il flag "Prevent saving changes.." sul menu tools-->options alla voce DESIGNERS.

>saluti
ciao!

--

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi

TOPOAMORE Profilo | Expert

695 messaggi | Data Invio: ven 4 giu 2010 - 18:03

Fianlmente....GRAZIE

vorrei farvi un'altra domanda in merito alla chiarezza.

Andando a progettare un'applicazione web (asp.net - vb.net) con associazione base dati (sql server 2008)
è meglio operare lato db per tutte le operazioni che si riescono a fare o suddividere il carico

nel senso:
se riesco a fare le operazioni a me necessarie(coneversioni tabelle, ecc..) lato db per porle gia in modo presentabile al front end è il metodo ottimale o conviene suddividere il carico???

non so se sono stato abbastanza chairo

__.__.__.__.__.__

ASP 2.0 - VB 2008

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: lun 7 giu 2010 - 00:22

>se riesco a fare le operazioni a me necessarie(coneversioni tabelle,
>ecc..) lato db per porle gia in modo presentabile al front end
>è il metodo ottimale o conviene suddividere il carico???
più che di carico effettivo parlerei di onere nell'effettuare un certo tipo di formattazioni o conversioni..
Se invece intendi carico dal punto di vista delle operazioni "pesanti" il discorso è differente.
Diciamo che per quanto riguarda il primo punto, direi che il database deve tornare sempre un tipo che il business si aspetta. Poi se il front end deve convertire o formattare il dato in un certo modo, è un "suo" problema. Un semplice esempio è dato dalle date, non effettuare su database la formattazione della stringa della data o di altri generi di stringa, lascia l'onere al livello di presentazione, è proprio un suo ruolo. Lo strato che va a leggere il dato deve avere strutture atte a contenere il dato nativo, passato dalla base dei dati, senza "ritocchi". Questo in linea di massima, anche per una migliore gestione delle operazioni eventuali di modifica (passare nome e cognome concatenati non ti consente un update sul campo calcolato, ma devi lavorare per effettuare l'operazione corretta).

Parlando invece di carico vero e proprio (overhead di rete, sovraccarico di calcoli non set based sul db) è sempre meglio capire come scrivere una struttura che sia scalabile, ovvero che, al crescere del carico, non vari i suoi comportamenti (non peggiori, diciamo..). Di conseguenza, preferisci operazioni set based su database e riduci al minimo calcoli ciclici in cui il database non è performante (vedi cursori, cicli, ecc..). Cerca di capire sempre dove spostare il peso. Più servizi che leggono dal database, elaborano su altre macchine, producono un set di dati per un eventuale aggiornamento sono meglio, ad esempio, di una query pesante che popola un cursore e che obbliga il database a impiegare la maggior parte delle sua potenza e della sua disponibilità per effettuare calcoli row by row..
Questo è solo un accenno, ogni realtà poi ha il suo caso specifico.. In linea di massima, è meglio usare il database dove è veramente forte, ovvero nelle operazioni sui set di dati.
--

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi

Torna su

Stanze Forum

Elenco Threads

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 !