Newsgroup: it.comp.lang.delphi
Titolo: Firebird e Blob

Scusate il titolo ma non sapevo cosa mettere..
 
Premessa: non mi intendo molto di data-base quindi chiedo a voi
 
Dunque, lavoro con firebird (embedded) e componenti uib ma credo che 
valga un po' per tutti:
 
Con questi componenti devo lavorare quasi esclusivamente tramite SQL e, 
per inserire un nuovo record uso una cosa simile
 
MainQuery.SQL.CLEAR;
MainQuery.SQL.Add('INSERT INTO Tabella1 (Campo1, Campo2, Campo3)0);
MainQuery.SQL.Add('VALUES (V1, V2, V3);');
MainQuery.Execute;
Transazione.CommitRetaining;
 
dove Campo1, Campo2, V1, V2, etc... ve li ho scritti inquesta maniera 
per non complicare troppo l'esempio.
 
Il problema è come faccio ad inserire uno o più campi blob in questo 
punto? Ho cercato in giro ma non ci ho capito molto, tutti gli esempi 
sono relativi ad un eventuale update futuro del record e nessuno spiega 
come passare un eventuale valore NULL, mi spiego:
 
la tabella, oltre a vari campi stringa, intero, float etc.. ha due campi 
blob che non sono altro che 2 immagini ma possono essere o tutte e due 
immagini valide o una sola valida o nessuna delle due
 
quindi le domande sono:
 
1) Nell'esempio sopra come faccio a passare i campi blob insieme agli 
altri parametri (sempre che sia possibile)
2) Nal caso una o più immagini non siano valide, come setto il campo a 
NULL (magari senza complicare troppo il codice)
 
Grazie a tutti,
David

Il blob è un campo rompiballe a prescindere dal db.
Non ricordo di aver usato un db c/s che permette di fare una insert into DIRETTA passando un blob. Le strade sono 2:
 
1) una query parametrica
Mi spiego come se usassi Dbx....
Definendo una query parametrica, hai la collection TParams.
Ongi istanza tparam ha un tipo di dato che, guarda caso, dovrà essere blob.
Cerca TBlobStream al solito posto, fermo restando che non conoscendo UIB non so se ha una sua classe da usare al posto di TBlobStream.
 
2) usi una stored procedure
Non so se un db embedded le supporta, cmq per dovere di cronaca cito anche questa cosa per un motivo...
Provata su Oracle (versioni sparse tra 9i, 10g e 11g, forse anche 8i) via ADO usando ovviamente (ma non per tutti) il provider OLEDB di Oracle e non quello Microsoft. 
La proc aveva un parametro blob e quando gli passavo piu di 4 k andava ai festini del nano di arcore. Questo usando delphi7.
Ergo, ho usato una query parametrica e poi:
 
AdoParam.LoadFromStream( SomeStream, ftvarBytes);
 
 
Riguardo il settare il campo a NULL..
 
Se usi ADo scrivi parametro.value := null.
Questo xche i kaz di TParameter non sono tipizzati e hanno solo la property Value ti tipo varian (puah!).
 
Se usi Dbx o BDe scrivi parametro.CLEAR.
 
A.

 NULL (magari senza complicare troppo il codice)
 
Poichè sto usando QT non riesco a darti una risposta puntuale, tuttavia 
il framework che usi dovrebbe già gestire i tipi BLOB in modo 
sufficientemente intelligente da distinguere se un field è NULL o meno.
 
Quando devo scrivere un blob, creo una query con questa semantica:
(query ripulita)
INSERT INTO WI_LOG_CSV_IMPORTED_TABLE (CSVZIPPED ) VALUES (:ZIP)
 
dopo chiamo un bindvalue sul parametro ZIP:
insert_qry.bindValue(":ZIP",ba);
dove il parametro ba per me è un ByteArray, tu cerca l'equivalente in 
delphi.
 
alla fine chiamo query.exec() e tutto funziona.
 
Questa il DDL della tabella (ripulita):
CREATE TABLE WI_LOG_CSV_IMPORTED_TABLE
(
   ID Integer NOT NULL,
   TABLE_NAME Varchar(50),
   TS_UPDATE Timestamp,
   RECORDS_INSERTED Integer,
   SECONDS_ELAPSED Integer,
   STR_ELAPSED_MM_SS Varchar(5),
   CSVZIPPED Blob sub_type 0,
   PRIMARY KEY (ID)
);
 
Come vedi il blob è definito come sub_type 0, come da faq: 
http://www.firebirdfaq.org/faq165/
 
 
 
-- 
morde
Android
QT 4.7
Delphi (5,6,7.. expired)
Firebird Database
 

Errata corrige:
 
TBlobStream e TAdoBlobStrem si usano se hai un TDataset e non per statement sql diretti tipo insert into.
 
 
A.

 Il blob è un campo rompiballe a prescindere dal db.
 
Concordo. La via migliore e` salvare il blob come file e mettere nel db un 
campo in cui si indica il path assoluto di dove si trova
 
Enrico


Non sono molto d'accordo con voi ;-)
 
Oggi il livello di maturità dei DB engines è tale da poter usare i blob 
senza controindicazioni.
L'espediente di usare un folder dove metterci tutti i file andava bene 
dieci anni fa, ma oggi non vedo valide ragioni per separare 
l'informazione dal suo storage naturale, il DB.
Piuttosto, ditemi in quali casi e con quali db e versioni avete avuto 
problemi di tal genere, in modo che mi documento.


 problemi di tal genere, in modo che mi documento.
io questo espediente l'ho implementato in un mio archivio su msql perché ogni anno le immagini aggiunte hanno un peso di oltre un giga. penso che aggiungere ad un db dati di questi dimensioni porti ad un decadimento delle prestazioni, inoltre all'atto pratico è molto più semplice nell'uso quotidiano se devo inviare un immagine come allegato prenderla direttamente dal percorso di rete che lanciare un applicativo per fare una estrazione dell'immagine stessa, ciao Brunello

 inviare un immagine come allegato prenderla direttamente dal percorso di rete 
 
Ihmo, usare un TBlobStream e creare un file temporaneo non la vedo una grossa complicazione.
 
A.
 
 

 campo in cui si indica il path assoluto di dove si trova
 
Avevamo un framework interno per gestire la persistenza dei dati.
Lo sforzo per aggiungere un po di logica per comprimere i dati in scrittura e decomprimerli in lettura era pari a ZERO.
SCONGIURAI il kapo di aggiungere questa logica.
Come diciamo a Napoli, manco p'o' cazzo.
alla fine il  db (db2 v7 di ibm)  è andato nei casini semplicemente per aver aggiunto ad una tabella un blob e sbattendoci dentro un xml tosto senza comprimerlo.
Casini nel senso di "tablespace pieni in quanto non progettati per contenere tutta quella mole di dati".
Dopo numerose urla del cliente di turno lo strato di compressione fu implementato di corsa (indovinate da chi) e il problema è sparito.
 
Un xml ha un ottimo rapporto di comperssione: di fatto è un testuale.
Ancora, le immagini jpg sono già compresse, i file pdf sono già compressi.
 
Questo per dire che  secondo me non c'è una "via migliore" a prescindere.
Magari in certi casi usare il filesystem puo' essere una buona soluzione.
Ma è sbagliato dare per scontato che TUTTI siano consapevoli delle controindicazioni:
 
1) permission come minimo a sola lettura per la cartella o le cartelle
Se il cliente ha dominio/active directory e/o magari un sistemista "MASTINO" ottenere questa cosa potrebbe non essere cosi SCONTATO. 
 
2) Impatto devastante qualora si decidesse di SPOSTARE i file.
Risolvibile, ma il tuo db DEVE ESSERE PROGETTATO PER TENER CONTO DI QUESTA EVENTUALITA' CHE REMOTA NON E'...
 
3) ticket di clienti che non vedono i kaz di file...per poi scoprire che qualche volpe ha cambiato permission ad un utente o ad un gruppo di utenti, spento il file server, cambiato indirizzo al file server...
Chi in questo NG non ha beccato almeno una volta casini di questo tipo?
 
4) necessità di un doppio backup
Il db senza i file NON TI SERVE, probabilmente
 
5) Il FILE SERVER VA GIU. Hai un backup di tutti i file ad un altro percorso di rete...Devi AL VOLO cambiare le mappature... Se usi la UNC, fammi capire come la reindirizzi. Se usi un unità di rete mappata, CHI VA IN GIRO SU TUTTI I CLIENT A CAMBIARE LA MAPPATURA DELLA MITICA UNIT X CHE CONTIENE LE IMAMGINI?
Oltre al CHI LO FA, questo lavoro CHI LO PAGA?
E quanfo il file server effettivo torna su, chi mette tutto a posto e chi paga per farlo?
 
Infine, parli di path "assoluto"....
Un path assoluto, se è come lo intendo io è fatto cosi:
 
1) \\server\cartella\sottocartella\file.jpg
2) x:\\cartella\sottocartella\file.jpg
 
Lasciamo stare il 2 che è da folli.
Ho 25 milioni di record. Decido di spostare i file.In 25 milioni di righe ho scritto quella stringa. Lo script sql per cambiarlo non è difficile, per carita.
Ma io useri 3 campi:
hostID
cartellaID
nome file
I primi 2 sono fk ad 2 tabelle: fileserverhost e fileserverfolder.
Indovina un po il xche...? :-D
 
 
Se invece decidi di usare i BLOB, prima c'è una fase preliminare che tanti non fanno: 
STUDIARE: SE e COME sono i gestiti i blob dl mio motore db
 
INFORMARSI: raccogliere info su eventuali problemi. Ad esempio i forum sul sito del produttore del motore db....
 
PROVARE: creare un db di prova simulando un carico di lavoro almeno DOPPIO rispetto a quello preventivato e valutando performance, tempi di risposta, spazio allocato etc...
 
Lo scopo è avere una risposta certa, basata su dati OGGETTIVI relativi al contesto e al perimetro delle funzionalità dell'applicazione.
Se la risposta è SI, lo step successivo è PROGETTARE  il db come si deve in funzione delle caratterische del motore db. Se il db ha i tablespace magari ha senso prevedere tablespace separati per i blob, ad esempio.
 
Ovviamente, io parlo di DATABASE, non di access.
 
A.
 
 
 
 
 

 Se la risposta � SI, lo step successivo � PROGETTARE  il db come
 >si deve in funzione delle caratterische
 >del motore db. Se il db ha i tablespace magari ha senso prevedere 
tablespace
 >separati per i blob, ad esempio.
 
I tablespace sono stati fatti apposta proprio per questo scopo: ad 
esempio ha senso mettere tutte le tabelle che riguardano il blob nello 
stesso tablespace, e i benefici li vedi nelle performances.
BTW, oggi per alcuni DB si pu� scrivere in un blob usando solo SQL.
 
Il sugo di tutta la storia, IMHO, � che evitare i BLOB � anacronistico, 
saperli usare bene (come hai gi� spiegato tu dettagliatamente) � 
fondamentale e imprescindibile.


 BTW, oggi per alcuni DB si può scrivere in un blob usando solo SQL.
 
..non va bene scoprire cosi' il fianco.
Adesso le domanda sono d'obbligo: quali? qlc esempio?   :D
 
 
A.


Parti da qui:
http://docs.oracle.com/cd/B10501_01/appdev.920/a96591/adl12bfl.htm
 
poi con google segui l'onda ;)


 segui l'onda ;)
 
il surf è troppo faticoso.
Meglio stare sul bagnasciuga a guardare il "panorama"... :-))))
 
 
A.


 senza controindicazioni.
 
Ni.
 
Firebird 1.5 + Delphi 7
 
Programma che gestisce seicentotrenta allievi, circa, divisi in due corsi.
 
Un'immagine per ogni allievo per facilitarne l'individuazione.
 
Non volevo usare il percorso, relativo o assoluto che sia, per i 
problemi di reperimento file che ci possono essere ed allora ho usato il 
campo blob.
 
Alla partenza del secondo corso, quello più corposo, m'hanno sparato 
dentro al db le immagini senza prima ridurle, ma direttamente come 
uscivano dalla fotocamera (circa 1MB ciascuna). Il db è quasi scoppiato. 
Gliele ho fatte ridurre (circa 8KB ciascuna) e siamo ritornati ad una 
dimensione accettabile. Da quel momento ho messo il limite a 15KB per 
immagine. Se sono più grandi non vengono nemmeno prese in considerazione.
 
Ma non è sempre possibile farlo perché magari devi avere delle immagini 
più dettagliate.
 
Non so come si comportano le nuove versione di FB in presenza di campi 
di grandi dimensioni.
 
Prima che mi massacriate vi dico che il progetto è *gratuito*, 
sviluppato per amicizia e quindi non ci perdo nemmeno tanto tempo dietro 
in ottimizzazioni. :)
 
-- 
@WarpTen10

 fondamentale e imprescindibile.
 
Il problema direi che sia soprattutto questo, perche` spesso richiede non 
solo e conoscenze per gestire un campo blob, ma richiede anche tecniche di 
programmazione particolari per essere sfruttato senza problemi. Per esempio, 
un'applicazione web in Java che sviluppano alcuni miei colleghi, andava 
spesso in OutOfMemoryException perche` nell'estrazione del file dal blob 
esso veniva caricato interamente in memoria, con tutte le conseguenze del 
caso
 
Enrico
P.S. giusto per la cronaca, io ragiono con path assoluti del tipo 
/srv/dati/immagini/immagine.png :)

 esso veniva caricato interamente in memoria
 
Dimenticavo, un altro motivo per gestire il blob su file sul file system e` 
proprio nell'ambito web, dove non e` per nulla detto che la macchina che 
serve i file statici (immagini, css, js...) sia la stessa che serve i 
contenuti dinamici (e che quindi dialoga con il database). E questo proprio 
per un discorso puramente prestazionale (considerate che mi e` stato pure 
suggerito di non mettere condivisioni di file system in mezzo tra i web 
server che servono i file statici e di sincronizzarli ogni tot minuti, 
proprio per evitare colli di bottiglia non desiderati)
 
Enrico


Ho realizzato negli ultimi anni due sistemi: il primo era (dico era 
perchï¿œ dato che funzionava l'hanno abbandonato...) la piattaforma di 
e-learning della Universitï¿œ di Bologna e il secondo il sistema 
informativo di una grossa fondazione di origine bancaria (non ï¿œ MPS!).
Nel primo caso web e java, nel secondo windows e delphi, in entrambi i 
casi Postgres con blob. Vivo felice e sereno perchï¿œ:
 
1) ho aggiunto un livello di sicurezza ai dati: quello del db
2) quando faccio i backup e restore vado liscio come l'olio
3) quando faccio le ricerche sul testo uso l'indicizzazione del db.
 
Perï¿œ uso Postgres, un db molto evoluto e quindi uso ad esempio 
l'ereditarietï¿œ delle tabelle e il meccanismo stored per cui le tabelle 
grandi sono divise in due parti: quella dinamica, contenente i 
documenti piï¿œ recenti, e quella statica, della quale faccio i backup 
una volta sola. Il programma le vede come una sola e posso tenere in 
linea lo storico dagli anni '90.
Non ho implementato la compressione perchï¿œ i documenti sono di tipo 
pdf, jpeg, excel o word, flash. Qualche problema, ma solo di 
performance, l'ho avuto con i file video perï¿œ era dovuto anche alla 
errata progettazione dei dati (nel caso e-learning si voleva un solo 
modulo didattico invece di piï¿œ moduli).
 
Ciao
 
 

 caso
 
Quindi la responsabilita' non è degli sviluppatori ma del blob..?
Quindi uso il filesystem xche non so usarli?
 
Uhm...
 
A.
 
 

 server che servono i file statici e di sincronizzarli ogni tot minuti, 
 
Il valore di  un suggerimento dipende dal suggeritore.
Troppi suggeriscono cose che NON HANNO MAI PROVATO.
Ma a parte cio', visto che di web non so un tubo, sarei curioso di sapere XCHE ci dovrebbe essere la necessita di usare delle condivisioni come quelle da te citate e xche dovrei sincronizzare ogni tot.
 
Infine, se non usi le condivisioni i file su filesystem come li vedi, scusa?
Magari mi sono perso un pezzo per strada...?
 
A.
 
 

 il limite a 15KB per immagine.
 
ecchisene frega? oggi lo storage non costa un pifefro!
al massimo un po di tempo in piu per i backup...ma capirai!

 Programma che gestisce seicentotrenta allievi
 
è ... e allora? se avevi  500mila movimenti di magazzino cazzo facevi?
ma vai a giocare coi videogames e lasciaci lavorare....pirla!

 ecchisene frega? oggi lo storage non costa un pifefro!
 
I problemi non erano (solo) di dimensioni del db, ma di tempo d'accesso. 
A peggiorare il tutto il fatto che il sw gira in una VM su una macchina 
non dedicata e quindi le prestazioni non sono il massimo, ma lì non sono 
io a prendere le decisioni.
 
-- 
@WarpTen10


A dire il vero il programma che gestisce 500mila movimenti di magazzino 
ce l'ho, ma lì il DB non contiene immagini.
 
-- 
@WarpTen10

 ma di tempo d'accesso
 
su 650 record?
 
scusa ...facci lavorare..qui siamo tutti professionisti!


cazzo centra bamboccione...il blob è un puntatore....studia bene...e poi 
ritorna!


Ho capito.
 
-- 
@WarpTen10


Ho capito.
 
-- 
@WarpTen10

 quelle da te citate e xche dovrei sincronizzare ogni tot.
 
La sincronizzazione (fatta con rsync o con qualcosa di simile) e` necessaria 
perche` ci siano gli stessi file su ogni macchina che ospita la webapp
 
Enrico

 Quindi uso il filesystem xche non so usarli?
 
Ok, qui direi di aver cannato alla grande, anche perche` ho notato solo ora 
che ci sono i metodi appositi per evitare che il blob venga caricato 
completamente in memoria (non ho mai usato direttamente questo tipo di dato) 
:)
 
Enrico

 Perche`, ripeto, chi serve i contenuti statici non ha accesso al database.
 
Ok, 'sta frase con tutto il resto non c'entra una beneamata :D
Riformulo:
 
"Perche` a livello prestazionale l'accesso al file system locale e` piu` 
veloce rispetto all'estrazione del blob dal database"
 
Se poi voglio rendere valida la frase che ho detto prima, basta mettere i 
contenuti statici direttamente sulla macchina del proxy (che, 
effettivamente, nel mio schema e` l'unica a non avere accesso al db) e siamo 
a posto :D
 
Enrico


Amlo il troll ogni tanto torna a seminare in ICLD..
 
Piuttosto, amlo, lo sai che con COBOL si possono gestire i BLOB in oracle?
http://docs.oracle.com/cd/A87860_01/doc/appdev.817/a76940/adl03pr7.htm
 
Fossi in te ci farei un pensierino.. e smettila di studiare java che 
tanto il pane, anzi la michetta, da mangiare non te lo dà mica il java.
;-)


 io a prendere le decisioni.
 
Questa cosa andrebbe studiata, perchè ho notizie di firebird grandi 
terabites (si, proprio TERA) e quindi non mi spiego il crollo di 
prestazioni.
Piuttosto, uso anche io delle macchine virtuali per fare esperimenti e 
mi accorgo che quando si satura la ram virtuale che gli assegno, vanno 
pesantemente sul disco fisso a fare swap.
 
Prova, se non ti costa troppo tempo,a portare fuori dalla macchina 
virtuale la app col db, a fare un programmino di test che carica 1000 
blob da 1 mega l'uno, e sopratutto fai l'upgrade del motore del db: oggi 
siamo stabili sulla 2.5 e vediamo già le prime beta della 3.0.
 
Ciao


 casi Postgres con blob. Vivo felice e sereno perchï¿œ:
 
Ecco questo ï¿œ un'ottimo study-case.
Sono sempre piï¿œ convinto che i DBMS oggi sono come delle potenti 
astronavi, che quasi tutti guidano col pilota automatico.
Ma solo studiandone a fondo l'architettura e i manuali d'uso si riesce a 
fare i viaggi interstellari..
 
Ecco, dopo questa sparata da fan di star trek, vado a studiarmi un pï¿œ 
Oracle.



È un progetto per me molto secondario, sviluppato per amicizia, ed al 
quale dedico parte del tempo libero (lo so, sono stupido, lo so).
 
Se il problema fosse stato più serio e ci fosse stata una *reale* 
necessità d'avere delle immagini ad alta risoluzione collegate ai dati 
(sia in un blob, sia come file memorizzato da qualche parte) avrei 
pensato ad una soluzione, ma m'è bastato porre il limite dei 15KB ed il 
problema è scomparso.
 
O meglio, il problema è solo stato allontanato perché, con l'andare del 
tempo, s'accumuleranno le immagini degli allievi (la fine delle lezioni 
non porta alla fine del corso), ma è un discorso molto al di là da venire.
 
L'aggiornamento del motore di FB è una delle opzioni, così come 
l'aggiornamento di Delphi anche se non sono più tanto sicuro di 
continuare ad usarlo per molto.
 
-- 
@WarpTen10

 ha senso prevedere tablespace separati per i blob, ad esempio. 
 
 
A.

 ;-)
 
a no? e cosa mi da da mngiare?

 vado a studiarmi un pï¿œ Oracle.
 
ecco bravo! per oggi di cazzate ne ha sparate abbastanza! ROTFL!

 
http://docs.oracle.com/cd/A87860_01/doc/appdev.817/a76940/adl03pr7.htm
 
 
ma e' roba vecchia quella liiiiii!!!!
nessuno usa piu i Pro*.
A parte che l'altro giorno parlavo con gente che fino a qualche anno fa 
lavorava ancora con le Form di Oracle....INCREDIBILE!
 
 

 a fare un programmino di test che carica 1000 blob da 1 mega l'uno,
 
anche te? non ci posso credere...ma chi cazzo se ne frega!!!!!!!
il campo blog è un puntatore!!!!!!!
studiatevi bene la differenza tra db record-oriented e db 
field-oriented...senò parlate di aria fritta. L'unico tempo perso è nei 
backup. E l'unico problema è lo storage! Il campo blob è un 
puntatore!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
incredibile!

 prestazioni.
 
Cosi`, al volo, l'unica cosa che mi viene in mente e` che i dati fossero 
frammentati. All'epoca, piu` per diletto che per vero uso, per risolvere il 
probolema scrissi questo:
 
#!/bin/python
import kinterbasdb
 
# Parametri di connessione (da impostare a discrezione dell'utente)
db_name="/home/ebianchi/db/test.fdb"
hostname="localhost"
username="sysdba"
pwd="masterkey"
 
def reindex():
    query_index=("SELECT RDB$INDEX_NAME FROM RDB$INDICES " +
                "WHERE COALESCE(RDB$UNIQUE_FLAG,0)<>1 " +
                "AND RDB$FOREIGN_KEY IS NULL " +
                "AND RDB$SYSTEM_FLAG<>1")
    con=kinterbasdb.connect(host=hostname, database=db_name,
                            user=username, password=pwd)
    cur=con.cursor()
    cur.execute(query_index)
    all_index=cur.fetchall()
 
    for index_name in all_index:
        print "Reindex " + index_name[0].strip()
        cur.execute("ALTER INDEX " + index_name[0].strip() + " INACTIVE")
        cur.execute("ALTER INDEX " + index_name[0].strip() + " ACTIVE")
        cur.execute("SET STATISTIC INDEX " + index_name[0].strip())
 
    cur.close()
    con.close()
 
if __name__ == "__main__":
    reindex()
 
Enrico

 Oracle.
 
Ti consiglio di vedere PostgreSQL. Non tanto perche` Oracle faccia schifo, 
ma perche` la licenza d'uso di PostgreSQL lo rende decisamente interessante
 
Enrico

 ma perche` la licenza d'uso di PostgreSQL lo rende decisamente interessante
 
Sto aspettando il momento di aprire un progetto dove il db sarà a mia 
scelta, e intendo usare PostgreSQL. Su oracle al momento sto solo 
facendo studio accademico.


> contesto e al perimetro delle funzionalità dell'applicazione.
 
Ma il discorso e` anche quello. Se hai una struttura complessa e devi 
garantire una certa responsivita` del sistema, devi fare delle scelte che 
potrebbero andare a complicare molto di piu` il tutto, ma che comunque ti 
garantiscono prestazioni migliori
 
Enrico

>  piedi qualcosa che funzioni, un lavoro cinofallico ci sta!
 
Mi intrometto nel thread perchè questo argomento è molto importante.
Gran parte dello stress cui siamo sottoposto dalle scadenze è perchè 
facciamo i lavori di fretta perchè la consegna dev'essere pronta 
"l'altro ieri".
Questo è il peggior modo di lavorare, essenzialmente per due motivi: il 
primo è che fai le cose di fretta e quindi ogni successiva modifica 
peggiora un sistema già compromesso, il secondo è che i lavori fatti 
male prima o poi ti tornano indietro costringendoti a spendere un tempo 
n volte maggiore per sistemare le inevitabili falle presenti, sia 
architetturali che funzionali.
 
Il primo punto su cui mi sono impegnato a migliorarmi è proprio questo: 
piuttosto passo un giorno intero a fare analisi e schizzare quattro 
classi un uml, e presentare un semilavorato flessibile e adattivo, 
piuttosto che gettarmi il giorno prima a scrivere codice copiando 
incollando come un matto e sfornare il lavoro "cinofallico".


 garantiscono prestazioni migliori
 
 
ah, ma lo scopo non è produrre un oggetto artistico ma uno STRUMENTO DI LAVORO che sia adatto al business di chi lo ha chiesto, fermo restando che parte del lavoro è anche far capire al clinete di turno che cio' che pensa NON VA BENE.
 
 
A.

 
Al solito, manca un pezzo che TU dai x scontato ma che di fatto non lo è.
La frase giusta è questa:
 
piuttosto, SE IL CLIENTE ME NE DA LA POSSIBILITA ED IL TEMPO,  passo un giorno intero a fare analisi e schizzare quattro ....
 
 
A.
 
 
 
 
Classi un uml, e presentare un semilavorato flessibile e adattivo, 


 Al solito, manca un pezzo che TU dai x scontato ma che di fatto non lo �.
 
No Alberto, non funziona sempre tutto cos�: il cliente chiede, e tu puoi 
anche rispondere picche.
E, avendo la fortuna ed il piacere di conoscerti anche di persona, so 
che tu sei proprio uno di quelli che non si fa mettere sotto dal 
cliente. O mi sbaglio?
 
Secondo me il punto � che bisogna sempre cercare un compromesso, quando 
ti trovi davanti al cliente pretenzioso.


 cliente. O mi sbaglio?
 
Se il cliente è UNA cliente, potrebbe anche valere la pena di farsi "mettere sotto"... e forse anche sopra e di lato.....
 
Molto dipende dal cliente...
Davanti ad una richiesta di un cliente a parecchi zeri che paga bene (e puntuale!) potrebbe valere la pena di sbattersi. Occhio al "potrebbe"!
 
Magari hai un framework che ti permette almeno di abbozzare qualcosa di non cinofallico da dargli con lo scopo di guadagnare tempo, magari puntando alle funzionalita' piu' urgenti sulle quali pero' si deve essere molto in gamba nello spremere le info al cliente....?
 
 
A.

 Magari hai un framework che ti permette almeno di abbozzare qualcosa di
 > non cinofallico da dargli con lo scopo di guadagnare tempo, magari 
puntando
 > alle funzionalita' piu' urgenti sulle quali pero' si deve essere
 > molto in gamba nello spremere le info al cliente....?
 
Framework al 50%, e il restante 50 � che sto cambiando il mio modo di 
lavorare, mi sto spostando su metodologie agili che ti permettono di 
costruire software adattivo e funzionale.


 piuttosto, SE IL CLIENTE ME NE DA LA POSSIBILITA ED IL TEMPO
 
Da noi questo discorso si sta cercando di affrontarlo seguendo quest'ottica: 
per $progetto ci voglino X giorni. Se $cliente chiede meno giorni, si 
aumentano le risorse allocate (e, conseguentemente, il costo del progetto)
 
Enrico

 Se non ci fosse qualcosa di spiacevole non si chiamerebbe lavoro.
 
Eh, da questo punto di vista sono d'accordo con Morde, anche perche` spesso 
mi sono ritrovato nella casistica che a causa della fretta ho scritto codice 
poco performante o prono ai bug, con tutti i problemi del caso
 
Enrico

Uff.Tecnico Comunale, archiviano i file vettoriali DXF di autocad, tutto 
vene fatto salvando in un Varchar il path "/server/directory/nomefile" 
di dove si trova un certo disegno
 
Ha senso usare un TMemoryStream per salvare il DXF in un campo Blob 
SubType 0 e poi quando serve aprirlo fare il processo inverso .SaveToFile.
 
Il sistema in uso non crea problemi, ma leggendo gli interventi a favore
forse si pu� migliorare la sicurezza, non credo le prestazioni
 
senza Blob :  -> eseguire Autocad -> aprire il file.
con Blob   :  ->.SaveToFile -> eseguire Autocad -> aprire il file.

 poco performante o prono ai bug, con tutti i problemi del caso
 
E' successo, succede e succedera' tutti.
Ci vuole la solita cosa ovvia (ma non per tutti): il buon senso.
Il buon senso è lo strumento che ti permette di decidere se violare le regole.
 
A.