Newsgroup: it.comp.lang.delphi
Titolo: Trim dei campi

Un salutone a tutti.
Ho iniziato da poco a lavorare su database SQL come SQLServer e Oracle e la
prima cosa che ho notato è che nei campi stringa se i dati immessi sono più
corti della dimensione del campo (es. 6 caratteri in un campo da 10) vengono
accodati delgi spazi fino al riempimento del campo stesso. Ho provato a
risolvere il problema usando delle query tipo 'SELECT LTRIM(NomeCampo1,
NomeCampo2, etc.) ma è un po' lunga come cosa ed oltretutto non sempre
funziona. C'è un modo in Delphi 5 di risolvere il problema (dati senza spazi
finali?)
Un grazie in anticipo
Gianfranco

Io uso SQL Server (e ho usato Interbase) e normalmente definisco i campi
come VARCHAR.
Con questo tipo di dato gli "spazi" non vengono accodati.
Ciao
Solid Snake IT

Scusa l'ignoranza, ma come ho detto uso da poco i database SQL, che
differenza c'è tra CHAR e VARCHAR? Ci sono Pro e Contro nell'uso degli uni
piuttosto che degli altri?
Nel frattempo grazie dell'info Solid Snake



Io ho lavorato con IB e definendo dei campi Varchar(X) e non ho mai avuto
questo problema (almeno, non mi pare...) ... In teoria il numero di byte
(caratteri) del campo deve definire solo il numero massimo di caratteri
immettibili, e non una costante per tutti i campi del record!
Cmq il tuo problema riguarda la dimensione del DB o la visualizzazione dei
suoi dati? Se il DB è piccolo dubito che ti accorgerai della differenza di
qualche byte (so che è fastidioso, ma non saprei come risolvere il tuo
problema), se il problema sta nella visualizzazione puoi utilizzare la
funzione Trim!
Ciao!
--
- Carlo -

 differenza c'č tra CHAR e VARCHAR? Ci sono Pro e Contro ...
Per quanto ne so, i campi CHAR, non essendo di lunghezza variabile, sono piů
performanti mente i VARCHAR, pur dovendo impostare una lunghezza massima,
memorizzano effettivamente il dato che scrivi.
Personalmente utilizzo SOLO i campi VARCHAR e non sento questo problemi di
"performance".
ciao
Solid Snake IT

 funzione Trim!
Purtroppo il database conta piů di 1.000.000 di record con un incremento di
circa 300 record l giorno, per questo mi preoccupo delle performance.

"Giandi74":
| Purtroppo il database conta più di 1.000.000 di record con un incremento
di
| circa 300 record l giorno, per questo mi preoccupo delle performance.
l'update da quanto ne so con un CHAR e' piu' veloce ma sprechi spazio,
con i varchar usi solo lo spazio utilizzato, l'update potrebbe
essere piu' lento ma utlizzando meno spazio ci stanno piu'
record in una sola pagina e quindi una ricerca costringe
il motore a meno letture su disco...
boh, io non saprei cosa consigliarti, anche se personalmente
uso sempre i varchar (tranne per stringhe molto corte
tipo 2/3 caratteri..)
Ciao,
Alan Solo

 tipo 2/3 caratteri..)
Io consiglio VarChar ...
Adesso non so quante tabelle ci siano, cmq parla di + di 1.000.000 di
record, supponiamo che in totale (tra tutte le tabelle) ci siano 5 campi
char, e supponiamo di perdere 4 byte da ciascuno di essi (4 mi sembrano pure
pochi ...)
In Totale sarà
4 * 5 * 1000000 = 20.000.000 Byte
                              (20.000.000 / 1024) / 1024 = Circa 20MB!!
Adesso so che il calcolo è molto approssimato (lo ho fatto con valori
"casuali") , cmq potrebbe essere anche peggio!
Non capisco in che fase i Char siano + performanti dei Varchar ....


"Carlo Bertuccini
| > boh, io non saprei cosa consigliarti, anche se personalmente
| > uso sempre i varchar (tranne per stringhe molto corte
| > tipo 2/3 caratteri..)
|
| Io consiglio VarChar ...
[...]
| Adesso so che il calcolo è molto approssimato (lo ho fatto con valori
| "casuali") , cmq potrebbe essere anche peggio!
hai ragione, in linea di massima anch'io consiglio i varchar..
| Non capisco in che fase i Char siano + performanti dei Varchar ....
non so bene come funziona internamente un RDMS (e probabilmente
e' implementato in modo diverso da uno all'altro) ma metti caso di avere
un campo Nome con valore "Alan" e l'utente lo vuole cambiare in "Pippo",
si aprono due strade:
- 1) nome e' un CHAR(10):
 se il RDMS e' furbo semplicemente sovrascrive "Alan" con "Pippo",
 tanto "Pippo" ci sta in 10 char
- 2) nome e' un  VARCHAR(10):
 il RDMS e' costretto ad appendere una nuova versione di tutto il record
 in un'altra posizione (quindi alla fine, oppure cercarsi uno spazio libero
 da qualche parte) perche' prima c'era "Alan" che occupava esattamente 4
byte,
 ora deve scrivere "Pippo" che ne occupa 5...
Non so se cio' che ho detto ha molto senso visto che _credo_ che solitamente
i record aggiornati non vengono sovrascritti ma ne viene cmq creata
un copia e quella vecchia viene solamente "flaggata"
boh!!
varchar e 1, varchar e 2 .... varchar e 3,
aggiudicato!! :)
Ciao,
Alan Solo

 Non capisco in che fase i Char siano + performanti dei Varchar ....
Decisamente Peggio (con la P maiuscola).
Seguendo il ragionamento e ammettendo che non ci siano grosse variazione
prestazionali dovrei risparmiare un bel po' di spazio. Quasi quasi modifico
tutto e passo ai Varchar. Ora il dubbio è:
In Oracle ho i Varchar e i Varchar2. Quale dei due?
Grazie ragazzi.

 In Oracle ho i Varchar e i Varchar2. Quale dei due?
Leggi l'Help e riporta le voci relative ad entrambe ... sinceramente non
conosco i Varchar 2 ...


"Giandi74":
| In Oracle ho i Varchar e i Varchar2. Quale dei due?
non li uso, ma guarda questo:
"Note: Currently, VARCHAR is synonymous with VARCHAR2. However, in future
releases of PL/SQL, to accommodate emerging SQL standards, VARCHAR might
become a separate datatype with different comparison semantics. So, it is a
good idea to use VARCHAR2 rather than VARCHAR."
e poi non dire che non siamo bravi! :)
Ciao,
Alan Solo

Non siete bravi SIETE DEI MITI :-) Grazie di cuore.
