Quale scegliere

[Stark]

Sono divenuto possessore felice di un Delphi XE7 in circostanze che non sto
qui a raccontare. L'ho installato a fianco del mio Delphi 2007 ed ho
improvvisamente deciso di fare il passo che ho sempre rinviato: Quella di
convertire la mia applicazione (che continuo a incrementare con nuove
funzioni ) all'uso di FireDAC al posto del BDE, dato che in teoria mi pare
di capire che il percorso di conversione non dovrebbe.
A questo punto, abbandonando il dBase, quale database scegliere ? Lo so che
ci sono vecchi post dove la domanda è stata posta più volte, ma il tempo è
passato, FireDAC non esisteva e molte altre cose sono cambiate. Le mie
esigenze non sono particolarmente sofisticate, perchè l'applicazione è stand
alone, monoutente e i volumi sono dell'ordine di poche decine di migliaia di
records. Vorrei che la installazione dell'applicazione non esigesse dei
prerequisiti e infine non vorrei spendere altri soldi.
Cosa consigliate ?


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
http://www.avast.com

[Warp10]

Post by Stark
Cosa consigliate ?

Firebird.

Gratuito, leggero e disponibile in modalità embedded che ti permette di
distribuire l'applicazione, l'engine ed i dati raccolti in un un'unica
directory purché ci sia un solo utente che usa il db per volta.

Lo uso da anni e mi ci trovo benissimo.

http://www.firebirdsql.org/

Per la gestione del database uso FlameRobin.

http://www.flamerobin.org/

Non so se esistono tool di conversione automatici dBase -> Firebird, ma
ho sempre diffidato di questi strumenti, preferendo sviluppare un mio
personale strumento ad hoc per sfruttare al meglio le caratteristiche di
Firebird.

Consiglio: essendoci passato anch'io dalla stessa transazione, molti
anni fa ma ho deviato per Paradox per un breve periodo e poi mi sono
indirizzato verso Interbase, non cercare similitudini tra dBase e
Firebird (o qualunque altro motore moderno sceglierai). Semmai ci
fossero sono pochissime e la loro ricerca potrebbe impedirti d'usare al
meglio il nuovo motore.

[Stark]

"Warp10" ha scritto nel messaggio news:matpc7$o60$***@speranza.aioe.org...
...........
anni fa ma ho deviato per Paradox per un breve periodo e poi mi sono
indirizzato verso Interbase, non cercare similitudini tra dBase e
Firebird (o qualunque altro motore moderno sceglierai). Semmai ci
fossero sono pochissime e la loro ricerca potrebbe impedirti d'usare al
meglio il nuovo motore.
@WarpTen10

Ma tu ora usi Interbase ?

---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
http://www.avast.com

[Warp10]

Post by Warp10
anni fa ma ho deviato per Paradox per un breve periodo e poi mi sono
indirizzato verso Interbase, non cercare similitudini tra dBase e
Firebird (o qualunque altro motore moderno sceglierai). Semmai ci
fossero sono pochissime e la loro ricerca potrebbe impedirti d'usare al
meglio il nuovo motore.
@WarpTen10
Ma tu ora usi Interbase ?

No, forse non sono stato chiaro.

Usavo Interbase e poi son passato a Firebird.

[a***@gmail.com]

Sono divenuto possessore felice di un Delphi XE7 in circostanze che non sto qui a raccontare.

Craccato. Come il 90% degli utilizzatori :)

Cosa consigliate ?

PostgreSQL. Anche MySQL e` una scelta, ma io preferisco il primo. Esistono i pgDAC che pero` sono a pagamento. Esiste un OLE DB Provider (che non credo abbia mai funzionato troppo bene con ADO su Delphi - ma e` tanto che non lo uso). Con FireDAC credo che tu riesca ad accederci.

[Marco Breveglieri]

A questo punto, abbandonando il dBase, quale database scegliere ? [...]

Esposta in questi termini, cioè senza porre dei requisiti specifici, chiunque ovviamente ti risponderà suggerendo il proprio database preferito, o quello che conosce meglio, che non è detto sia anche il tuo.

Aggiungi qualche dettaglio in più, ad esempio il tipo di applicazioni che intendi svilupparci, la piattaforma di tuo interesse, gli aspetti a cui vuoi dare maggiore risalto (prestazioni, portabilità, ecc.).

FireDAC deriva da AnyDAC ed è una libreria a mio avviso molto curata e ricca di funzionalità.

Ad esempio, io l'ho messo alla prova con SQL Server, e si è comportato decisamente bene.

Se vuoi approfondire FireDAC e le sue funzionalità, ci sono parecchi video a riguardo:
https://www.youtube.com/results?search_query=firedac

Buon lavoro!
Marco.

[Stark]

A questo punto, abbandonando il dBase, quale database scegliere ? [...]

Aggiungi qualche dettaglio in più, ad esempio il tipo di applicazioni che
intendi svilupparci, la piattaforma di tuo interesse, gli aspetti a cui vuoi
dare maggiore risalto (prestazioni, portabilità, ecc.).
Marco.

E' guardando una di queste presentazioni di FireDAC dove ne vantavano la
particolare predisposizione alla migrazione dal BDE che La mia decisione era
maturata. Inoltre, installando XE7 non ho più trovato il BDE e quindi mi
sono detto che era arrivata l'ora.
Tanto più che le mie esigenze sono abbastanza elementari, perchè non
sviluppo applicazioni mutliutente o Client Server, ma applicazioni
monoutente, con volumi di transazioni e necessità di archiviazione limitata,
in ambiente Windows.
Mi pareva di aver capito che ci sono database dove si ritrovano i classici
oggetti TTable e TQuery del BDE.
O è meglio che lasci perdere ?


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
http://www.avast.com

[Alberto Salvati]

Io non ho MAI detto che NON devi mollare il BDE.
Ti sto solo suggerendo, prima di partire a testa bassa, di VALUTARE TEMPI E IMPATTI.

Post by Stark
i pareva di aver capito che ci sono database dove si ritrovano i classici
oggetti TTable e TQuery del BDE.

Comincia poi a chiarirti le idee..

Un *database* non ha oggetti tipo TQuery, TAdoQuery, TTable, TSqlQuery TFDQuery etc.
BDE, ADO, FIREDAC, DOA, DBX non sono database: sono *tecnologie di accesso ai dati*.
I database sono Db2, Sybase, PostGres, Interbase, Oracle, FireBird, MySql...etc
Paradox è un database, BDE NO!
Infatti con BDE puoi colegarti a database di tipo diverso: oracle, sqlserver etc e addirittura a fonti dati ODBC.

IL PRIMO STEP CONSISTE NELL'AVERE LE IDEE BEN CHIARE SU COME FUNZIONA UN DB C/S E SU COSA NON SERVE O NON VA FATTO QUANDO LO SI USA.

Post by Stark
Si, adesso lavoro con TTable e TQuery. Non c'č un
ambiente analogo ?

per le Tquery si.
Quello è un tipo di oggetto che esiste a prescindere dalla tecnologia. Su dbx hai TSqlQuery, su ADO hai TAdoQuery e su FireDac hai TFDQUery.

La rogna è per le TTable.
Visto che usi già TQuery non credo servano spiegazioni sulle differenze che esistono tra questa e una TTable. Quindi:

1) ora usi BDE con TTable e TQuery presumo su Paradox o dbase, giusto?

2) vuoi passare ad un db client/server e mollare BDE per passare a FireDac. Ottimo

3) le TQuery, in linea di massima, le sostituisci in modo quasi indolore, salvo qualche peculiarita di BDE...
Non ricordo se era TQuery che aveva il requestlive, ad esempio

4) dovresti (notare il condizionale!) evitare di usare oggetti "tabella" su un db client/server. Quindi dovresti (!) *sostituire* le TTable con delle query


Quindi:

Se una una form funziona sfruttando caratteristiche peculiari di TTable, nel sostituire tale oggetto con una TxxQuery, *potresti* aver necessità di cambiare il tuo codice.

Ad esempio, la property IndexName non ha equivalente su un ogegtto Query. E se una tua form ha un qualcosa per impostare l'ordinamento di una griglia che si basa su indexname devi modificare la tua form.

Ovviamente, ma non per tutti, queste considerazioni non valgono un tubo se firedac ha qualcosa per un porting indolore.

Ma personalmente, prima di rischiare DANDO PER SCONTATO CHE TUTTO FUNZIONI BASANDOMI SU UNA PRESENTAZIONE, ribadisco che IO farei una analisi e delle prove per cercare di capire a cosa potrei andare incontro.


Pensa anche a cosa usi come primary key ed eventualmente a come le calcoli.
Hai dei progressivi, tabelle di contatori, campi con immagini e/o altri dati binari, blob, clob etc?

L'aspetto prestazionale è certamente importante, ma non esiste solo quello.

A.




a.

[Stark]

Post by Stark
Si, adesso lavoro con TTable e TQuery. Non c'č un
ambiente analogo ?

per le Tquery si.
Quello è un tipo di oggetto che esiste a prescindere dalla tecnologia. Su
dbx hai TSqlQuery, su ADO hai TAdoQuery e su FireDac hai TFDQUery.
La rogna è per le TTable.
................................................................
Si hai ragione, ma capisco abbastanza la differenza tra il database e la
tecnologia per l'accesso ai dati. In effetti come database, ho sempre usato
dBase. In un primo tempo usando estensivamente la TTable, poi ho imparato ad
usare molto di più le TQuery quando mi sono reso conto che anche con il
local Sql potevo fare, non dico tutto, ma quasi.
Nel mio database non uso campi di tipo particolare, salvo i campi Memo.
Da quello che ho letto nelle risposte ricevute, potrei scegliere tra
Firebird e SQLite, che coprirebbero la parte TQuery. Ma Marco mi dice che
FireDAC ha anche delle Tables (quindi FireDAC non è solo un coso per dare
accesso a dei database ??).
A meno di non usare Interbase, visto che è gratis mi pare, a meno che non
sia troppo, e poi non lo nomina nessuno ...


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
http://www.avast.com

[a***@gmail.com]

Interbase, [...] non lo nomina nessuno ...

Ci sara` un motivo.

[Marco Breveglieri]

Post by Stark
E' guardando una di queste presentazioni di FireDAC dove ne vantavano la
particolare predisposizione alla migrazione dal BDE che La mia decisione era
maturata.

Vero, ci sono molti componenti simili nelle proprietà che espongono, anche se il "cuore" è differente.

Post by Stark
Inoltre, installando XE7 non ho più trovato il BDE e quindi mi
sono detto che era arrivata l'ora.

Sì, anche perché è deprecato già dal 2001, quindi sono 14 anni che è ora. :)

E' stato rimosso in XE7 poiché non ha più senso continuare a distribuirlo visto che supporta solamente un tipo di progetto, ossia applicazioni *non* multi-device per Windows (quindi solo VCL, non FireMonkey) ed esclusivamente a 32 bit (non 64).

Post by Stark
Tanto più che le mie esigenze sono abbastanza elementari [...]

Non fare mai troppe previsioni su quanto potrebbe espandersi l'applicazione che realizzi. ;)

Post by Stark
Mi pareva di aver capito che ci sono database dove si ritrovano i classici
oggetti TTable e TQuery del BDE.
O è meglio che lasci perdere?

Hai provato ad utilizzare i componenti di FireDAC che sono "omonimi" (salvo il prefisso, ovviamente) di quelli del BDE, tipo la TFDTable?

Inoltre, anche se la migrazione è facilitata, conviene che acquisisci dimestichezza comunque sulle funzionalità di FireDAC per evitare problemi di qualsiasi tipo derivanti da assunzioni errate sul funzionamento della libreria.

Ciao,
Marco.

[Stark]

"Marco Breveglieri" ha scritto nel messaggio news:5360052a-c7e5-498a-add9-***@googlegroups.com...
Hai provato ad utilizzare i componenti di FireDAC che sono "omonimi" (salvo
il prefisso, ovviamente) di quelli del BDE, tipo la TFDTable?
...
Marco.

Se, come dici, FireDAC ha l'equivalente delle TTable, potrei cominciare ad
esplorare FireDAC (che io credevo non avesse questi componenti database. Ma
non è che ha anche un "omonimo" TQuery?).

Altrimenti, da quello che ho letto nelle risposte ricevute, mi orienterei su
Firebird o SQLite. Ma c'è il rischio di ritrovarsi tra un pò come con il
dBase? E quale dei due ? E perchè nessuno consiglia Interbase ?


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
http://www.avast.com

[a***@gmail.com]

Post by Stark
Altrimenti, da quello che ho letto nelle risposte ricevute, mi orienterei su
Firebird o SQLite. Ma c'è il rischio di ritrovarsi tra un pò come con il
dBase? E quale dei due ?

http://docwiki.embarcadero.com/RADStudio/XE6/en/Tutorial:_Connecting_to_a_SQLite_Database_Using_FireDac

Post by Stark
E perchè nessuno consiglia Interbase?

E perche` nessuno consiglia JBuilder? E perche` nessuno consiglia C++Builder?
Perche` sono prodotti che non esistono sul mercato, non sono utilizzati praticamente da nessuno, e su cui nessuno investirebbe un solo soldo.
Anche per Firebird e` la stessa cosa: ti sfido a trovare documentazione e supporto se hai un problema.

[Marco Breveglieri]

Post by Stark
Se, come dici, FireDAC ha l'equivalente delle TTable, potrei cominciare ad
esplorare FireDAC (che io credevo non avesse questi componenti database. Ma
non è che ha anche un "omonimo" TQuery?).

Scusa, ma non hai detto di possedere Delphi XE7?
Dai un'occhiata alla toolbox dei componenti FireDAC e in pochi minuti puoi vedere se c'è il componente che cerchi oppure no, senza stare a chiederlo qui. :)

Post by Stark
Altrimenti, da quello che ho letto nelle risposte ricevute, mi orienterei su
Firebird o SQLite. Ma c'è il rischio di ritrovarsi tra un pò come con il
dBase? E quale dei due ? E perchè nessuno consiglia Interbase?

Perché dici "altrimenti"? Guarda che FireDAC, come ti ha già detto Alberto Salvati, *non* è un database: è una libreria di accesso ai dati, cioè una libreria per collegarti e interrogare il database che scegli di utilizzare, qualunque esso sia (purché esista un driver FireDAC, ma ce n'è praticamente per qualsiasi DB).

Se vuoi migrare dal BDE, FireDAC è un'ottima scelta, poi il database è un altro paio di maniche.

InterBase non te lo consiglierei perché sarebbe inutile per te usare un database commerciale per caratteristiche che non sfrutteresti dato i requisiti che hai posto, ossia un accesso in locale e praticamente esclusivo, non client/server, senza necessità specifiche di sicurezza, backup, gestione utenti, ecc.

Ciao,
Marco.

[Stark]

"Marco Breveglieri" ha scritto nel messaggio news:825abcba-9ca5-48e9-9e04-***@googlegroups.com...
InterBase non te lo consiglierei perché sarebbe inutile per te usare un
database commerciale per caratteristiche che non sfrutteresti dato i
requisiti che hai posto, ossia un accesso in locale e praticamente
esclusivo, non client/server, senza necessità specifiche di sicurezza,
backup, gestione utenti, ecc.
Ciao,
Marco.

Ho installato XE7 su un PC che per qualche settimana non avrò disponibile.
Nel frattempo, cercavo di documentarmi, ma vedo che non è facile capire. Ho
capito che Database e libreria di accesso sono due cose distinte. Ma mi
pareva che proprio tu avessi scritto "Hai provato ad utilizzare i componenti
di FireDAC che sono "omonimi" (salvo il prefisso, ovviamente) di quelli del
BDE, tipo la TFDTable?".
Quindi ha pensato che FireDAC avesse qualcosa in più. Se non è così, cosa
volevi dire ?
Per il momento, nella mia mente ho scartato InterBase per quello che mi hai
detto tu, Firebird per quello che mi ha detto Laforgia e mi sono documentato
su SQLite, MySql e Postgres.
Per la conversione delle mie attuali applicazioni, sarei tentato da SQLite,
perchè mi appare il più semplice e risponde alle esigenze di queste
applicazioni. Ho però qualche dubbio che chi usa SQLite mi potrebbe
chiarire: Per esempio, non esiste un tipo di campo DATE, nè un tipo di campo
Memo. Come si fa con dati di questo tipo?
Non risolvo il problema delle TTable, usate abbastanza estensivamente.
Problema che comunque avrei anche con MySql e Postgres.
La conversione a FireDAC/SQLite potrebbe rivelarsi eccessivamente pesante
rispetto al vantaggio di abbandonare una tecnologia obsoleta, ma ancora
perfettamente funzionante ?
Non lo so, non mi pare di avere ancora abbastanza elementi per decidere.


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
http://www.avast.com

[Warp10]

Post by Stark
La conversione a FireDAC/SQLite potrebbe rivelarsi eccessivamente
pesante rispetto al vantaggio di abbandonare una tecnologia obsoleta, ma
ancora perfettamente funzionante ?

---
dBase: devo cancellare una fattura
1 - cancello tutte le righe
2 - cancello l'intestazione

Database C/S: devo cancellare una fattura
1 - cancello l'intestazione
le righe vengono cancellate automaticamente perché collegate
all'intestazione tramite foreign key che tu imposti
---
dBase: devo assegnare un ID al nuovo cliente
1 - vado a vedere qual è l'ultimo ID dei clienti assegnato
2 - lo incremento di 1
3 - lo assegno al nuovo cliente
E devo stare attento che un'altra istanza del software non stia facendo
la stessa operazione nello stesso momento. Se così fosse assegnerei lo
stesso ID a due clienti diversi.

Database C/S: devo assegnare un ID al nuovo cliente
1 - inserisco il nuovo cliente
l'ID viene calcolato tramite uno strumento del motore del database (in
Firebird si chiamano generators). In questo modo sono certo che non ci
potranno mai essere due clienti con lo stesso ID.

La stessa cosa vale per qualunque nuovo elemento di una tabella
(clienti, fornitori, fatture, righe di fatture...)
---
dBase: ho bisogno la ragione sociale del cliente di ogni fattura
1 - leggo l'ID del cliente dalla fattura
2 - recupero la ragione sociale dalla tabella clienti
3 - scrivo la ragione sociale in un campo calcolato
o
1 - creo un campo di tipo lookup che va a leggere la ragione sociale da
una TTable che contiene l'elenco clienti ordinato per ID

Database C/S: ho bisogno di vedere la ragione sociale del cliente di
ogni fattura
1 - con una JOIN tramite due campi chiave (ID del cliente nella fattura
ed ID cliente nell'elenco clienti) faccio recuperare al database la
ragione sociale del cliente
---
dBase: per usare il tuo software in rete le tabelle devono essere
disponibili in una cartella condivisa

Database C/S: per usare il tuo software in rete hai solo bisogno di
sapere qual è l'IP del PC dove gira il server di database. Niente
cartelle condivise. Questo è l'ambiente classico d'uso di FB e di altri
database C/S.
---
Database C/S: transazioni
l'utente cambia idea all'ultimo momento e non vuole memorizzare le
operazioni che ha portato avanti fino a quel momento.
Rollback.
---

Altre persone di questo NG potrebbero farti altri esempi.

Dovrai riscrivere tutto, ovviamente, ma otterrai grandi vantaggi e meno
problemi.

[Warp10]

Post by Stark
La conversione a FireDAC/SQLite potrebbe rivelarsi eccessivamente
pesante rispetto al vantaggio di abbandonare una tecnologia obsoleta, ma
ancora perfettamente funzionante ?

Dimenticavo gli eventi.

Nel db succede qualcosa (nuovo cliente, nuova fattura, modifica riga
della fattura...) puoi scatenare un evento che può essere intercettato
tramite un componente apposito all'interno della tua applicazione e fare
qualcosa come aggiornare l'elenco clienti, l'elenco fatture, le righe
della fattura...

Firebird li ha e mi pare esistano in altri db.

[Morde]

Post by Warp10
Firebird li ha e mi pare esistano in altri db.

Io li ho usati: dopo due settimane di problemi, li ho disattivati..

Gli eventi vengono propagati attraverso porte, che comporta la gestione
dei firewall, e questo aggiunge un onere in più per te.

Oltre a questo, ogni client apre una connessione in ascolto per
verificare se dal socket arrivano dati, e devi tenerne conto se non vuoi
che il firewall locale ti lasci a piedi.

Alla fine ho risolto usando una tabella dove registro gli eventi, e dei
thread lato client che fanno polling. Non pulitissimo, ma funzionale, e
tutto relegato alla connessione col database.

Per documentarti sugli eventi:
http://www.firebirdsql.org/file/documentation/papers_presentations/Power_Firebird_events.pdf

[Warp10]

Post by Morde

Post by Warp10
Firebird li ha e mi pare esistano in altri db.

Io li ho usati: dopo due settimane di problemi, li ho disattivati..
Gli eventi vengono propagati attraverso porte, che comporta la gestione
dei firewall, e questo aggiunge un onere in più per te.
Oltre a questo, ogni client apre una connessione in ascolto per
verificare se dal socket arrivano dati, e devi tenerne conto se non vuoi
che il firewall locale ti lasci a piedi.
Alla fine ho risolto usando una tabella dove registro gli eventi, e dei
thread lato client che fanno polling. Non pulitissimo, ma funzionale, e
tutto relegato alla connessione col database.
http://www.firebirdsql.org/file/documentation/papers_presentations/Power_Firebird_events.pdf

Per mia fortuna li ho usati senza problemi in una configurazione all-XP.

So già che appena passeranno a 7/8 inizieranno i problemi, ma mi sto già
premunendo. :)

[Warp10]

Post by Warp10

Post by Morde

Post by Warp10
Firebird li ha e mi pare esistano in altri db.

Io li ho usati: dopo due settimane di problemi, li ho disattivati..
Gli eventi vengono propagati attraverso porte, che comporta la gestione
dei firewall, e questo aggiunge un onere in più per te.
Oltre a questo, ogni client apre una connessione in ascolto per
verificare se dal socket arrivano dati, e devi tenerne conto se non vuoi
che il firewall locale ti lasci a piedi.
Alla fine ho risolto usando una tabella dove registro gli eventi, e dei
thread lato client che fanno polling. Non pulitissimo, ma funzionale, e
tutto relegato alla connessione col database.
http://www.firebirdsql.org/file/documentation/papers_presentations/Power_Firebird_events.pdf

Per mia fortuna li ho usati senza problemi in una configurazione all-XP.

All-XP e without-firewall, ovviamente.

[Alberto Salvati]

Post by Warp10
Database C/S: devo cancellare una fattura
1 - cancello l'intestazione
le righe vengono cancellate automaticamente perché collegate
all'intestazione tramite foreign key che tu imposti

Esatto ma incompleto.
Un altra opzione è "se esistono record di dettaglio, blocca."
PRIMA CANCELLI ESPLICITAMENTE LE RIGHE DI DETTAGLIO, DOPO CANCELLI LA MASTER.
Poi c'è l'altra che è "sul dettaglio imposta a NULL il campo di collegamento al record master (mai usato).
Altra cosa che non hai citato è lo svantaggio delle foreign key.
Se devi fare import ed export, sei costretto, salvo vari meccanismi, a rispettare l'ordine con il quale importi i tuoi dati.
Nel caso delle fatture, dovresti quindi scrivere prima i record i testata e poi quelli di dettaglio.
Non so se tutti i database hanno degli escamotage per "rimandare" queste validazioni, Oracle si.


detto è che l

Post by Warp10
Database C/S: devo assegnare un ID al nuovo cliente
1 - inserisco il nuovo cliente
l'ID viene calcolato tramite uno strumento del motore del database (in
Firebird si chiamano generators). In questo modo sono certo che non ci
potranno mai essere due clienti con lo stesso ID.

Occhio che non tutti i database hanno un qualcosa tipo i generators (firebird e interbase) o le sequences (Oracle).

Post by Warp10
1 - con una JOIN tramite due campi chiave (ID del cliente nella fattura
ed ID cliente nell'elenco clienti) faccio recuperare al database la
ragione sociale del cliente

Giusto. Ma meglio aggiungere che :

1) le operazioni di join su una grossa mole di potrebbero essere pesanti
2) sui documenti fiscali alcuni dati dovrebbero essere ridondanti.
Con "alcuni dati" intendo "quelli che, se modificati, produrrebbero documenti fiscali e non diversi se ristampati a distanza di tempo".
3) su versioni di oracle precedenti all 9 il costrutto JOIN non era supportato.

Post by Warp10
Database C/S: per usare il tuo software in rete hai solo bisogno di
sapere qual è l'IP del PC dove gira il server di database. Niente
cartelle condivise. Questo è l'ambiente classico d'uso di FB e di altri
database C/S.

Il non avere le cartelle condivise è una di quelle cose che GISUTAMENTE rende felici i sistemisti.

A.

[Warp10]

Post by Alberto Salvati

Post by Warp10
Database C/S: devo cancellare una fattura
1 - cancello l'intestazione
le righe vengono cancellate automaticamente perché collegate
all'intestazione tramite foreign key che tu imposti

Esatto ma incompleto.
Un altra opzione è "se esistono record di dettaglio, blocca."
PRIMA CANCELLI ESPLICITAMENTE LE RIGHE DI DETTAGLIO, DOPO CANCELLI LA MASTER.
Poi c'è l'altra che è "sul dettaglio imposta a NULL il campo di collegamento al record master (mai usato).
Altra cosa che non hai citato è lo svantaggio delle foreign key.
Se devi fare import ed export, sei costretto, salvo vari meccanismi, a rispettare l'ordine con il quale importi i tuoi dati.
Nel caso delle fatture, dovresti quindi scrivere prima i record i testata e poi quelli di dettaglio.

Svantaggio minimo, direi, rispetto ai vantaggi. Comunque è vero.

Post by Alberto Salvati
detto è che l

?

Post by Alberto Salvati

Post by Warp10
Database C/S: devo assegnare un ID al nuovo cliente
1 - inserisco il nuovo cliente
l'ID viene calcolato tramite uno strumento del motore del database (in
Firebird si chiamano generators). In questo modo sono certo che non ci
potranno mai essere due clienti con lo stesso ID.

Occhio che non tutti i database hanno un qualcosa tipo i generators (firebird e interbase) o le sequences (Oracle).

Ecco perché il fatto di averli o non averli a disposizione dovrebbe
essere una delle caratteristiche da prendere in considerazione per la
scelta del db da usare.

Post by Alberto Salvati

Post by Warp10
1 - con una JOIN tramite due campi chiave (ID del cliente nella fattura
ed ID cliente nell'elenco clienti) faccio recuperare al database la
ragione sociale del cliente

1) le operazioni di join su una grossa mole di potrebbero essere pesanti

"su una grossa mole di" dati (presumo) tutto è pesante. :)

A parte gli scherzi, io le uso su diverse centinaia di migliaia di
record (non è una grossa mole, d'accordo, ma è il database più popolato
da dati reali che ho, finora), con tabelle opportunamente indicizzate,
ed ottengo risultati più che soddisfacenti per il cliente. E se non si
lamenta lui, per me va bene. :)

Post by Alberto Salvati
2) sui documenti fiscali alcuni dati dovrebbero essere ridondanti.
Con "alcuni dati" intendo "quelli che, se modificati, produrrebbero documenti fiscali e non diversi se ristampati a distanza di tempo".

Giusto. Se il mio cliente cambia ragione sociale nel frattempo, devo
stampare quella vecchia e non quella nuova. Ma era solo il primo esempio
che m'è venuto in mente.

Post by Alberto Salvati
3) su versioni di oracle precedenti all 9 il costrutto JOIN non era supportato.

Sono riuscito ad evitare Oracle finora e spero di riuscire a farlo anche
in futuro. Un mio cliente sta dismettendo un software, al quale un mio
software si sarebbe dovuto interfacciare, che si basava su Oracle.
Doveva essere scritto coi piedi perché non ho mai visto niente di più
bradipamente lento.

Post by Alberto Salvati

Post by Warp10
Database C/S: per usare il tuo software in rete hai solo bisogno di
sapere qual è l'IP del PC dove gira il server di database. Niente
cartelle condivise. Questo è l'ambiente classico d'uso di FB e di altri
database C/S.

Il non avere le cartelle condivise è una di quelle cose che GISUTAMENTE rende felici i sistemisti.

E visto che, qualche volta, i sistemisti siamo noi ci auto-rendiamo
felici. :)

[a***@gmail.com]

On Monday, 9 February 2015 10:49:09 UTC, Warp10 wrote:

[...]

Post by Warp10
Ecco perché il fatto di averli o non averli a disposizione dovrebbe
essere una delle caratteristiche da prendere in considerazione per la
scelta del db da usare.

Direi di no, perche` costruire un autoincrementale, se il db non te lo offre, e` una sciocchezza.

Post by Warp10
"su una grossa mole di" dati (presumo) tutto è pesante. :)

Ma le JOIN sono tra le cose piu` pesanti.

Post by Warp10
Sono riuscito ad evitare Oracle finora e spero di riuscire a farlo anche
in futuro. Un mio cliente sta dismettendo un software, al quale un mio
software si sarebbe dovuto interfacciare, che si basava su Oracle.
Doveva essere scritto coi piedi perché non ho mai visto niente di più
bradipamente lento.

Se il software era scritto coi piedi, che c'entra Oracle?

[Warp10]

Post by a***@gmail.com
[...]

Post by Warp10
Sono riuscito ad evitare Oracle finora e spero di riuscire a farlo anche
in futuro. Un mio cliente sta dismettendo un software, al quale un mio
software si sarebbe dovuto interfacciare, che si basava su Oracle.
Doveva essere scritto coi piedi perché non ho mai visto niente di più
bradipamente lento.

Se il software era scritto coi piedi, che c'entra Oracle?

Nulla.

Ma se il software era scritto coi piedi presumo che anche la struttura
dati in Oracle seguisse la stessa metodologia. E quindi sia lodato chi
ha scelto di dismettere il tutto.

[a***@gmail.com]

On Monday, 9 February 2015 11:38:28 UTC, Warp10 wrote:

[...]

Post by Warp10
Ma se il software era scritto coi piedi presumo che anche la struttura
dati in Oracle seguisse la stessa metodologia. E quindi sia lodato chi
ha scelto di dismettere il tutto.

Ma se esordisci con un "Sono riuscito ad evitare Oracle finora e spero di riuscire a farlo anche in futuro." fai capire che e` bene stare alla larga da Oracle. Quando invece quel che volevi dire, probabilmente, e` che bisogna stare alla larga da gente che scrive software coi piedi. Su questo non posso che concordare. Oracle e` un ottimo strumento, uno dei migliori database in circolazione, affidabile e veloce.

[Warp10]

Post by a***@gmail.com
[...]

Post by Warp10
Ma se il software era scritto coi piedi presumo che anche la
struttura dati in Oracle seguisse la stessa metodologia. E quindi
sia lodato chi ha scelto di dismettere il tutto.

Ma se esordisci con un "Sono riuscito ad evitare Oracle finora e
spero di riuscire a farlo anche in futuro." fai capire che e` bene
stare alla larga da Oracle. Quando invece quel che volevi dire,
probabilmente, e` che bisogna stare alla larga da gente che scrive
software coi piedi. Su questo non posso che concordare. Oracle e` un
ottimo strumento, uno dei migliori database in circolazione,
affidabile e veloce.

"Sono riuscito ad evitare Oracle finora e spero di riuscire a farlo
anche in futuro." proprio perché so che è un motore di database
complesso da far girare al meglio. Richiede personale competente e
qualificato che, a volte, è assente perché, guarda caso, costa troppo.

Se io devo interfacciare con un mio programma con un database Oracle e
dall'altra parte non ho informazioni di alcun tipo perché la vecchia
software house non vuole darne (questo era lo scenario che mi si
prospettava) so già che andrò ad infilarmi in un ginepraio da cui
difficilmente uscirò vivo. La cosa andava avanti da anni e finalmente la
soluzione è arrivata.

Lunga vita ad Oracle, beninteso, basta che ci sia qualcuno che mi dice
dove devo leggere le cose e cosa significano.

[Alberto Salvati]

Post by Warp10
proprio perché so che è un motore di database
complesso da far girare al meglio. Richiede personale competente e
qualificato che, a volte, è assente perché, guarda caso, costa troppo.

Alcuni anni fa il percorso di certificazione Oracle costava tra corsi ed esami intorno ai 18.000 euro.
Lo so in quanto avevo fatto una valutazione.

Considerando cio' e considerando che e' molto difficile che si riesca a fare ALTRO, chi ha quel tipo di qualifica ha tutto il diritto di chiedere certe cifre.

Il problema non è tanto di quanto costi oracle in se o di quanto costi uno specialista che ne risolve i casini.
Il problema è fare una SCELTA CONSAPEVOLE, non basata sul trafiletto letto sull'espresso o sul cugggino che in azienda usa Oracle "che è una bomba".

A.

[Warp10]

Post by Alberto Salvati

proprio perché so che è un motore di database complesso da far
girare al meglio. Richiede personale competente e qualificato che,
a volte, è assente perché, guarda caso, costa troppo.

Alcuni anni fa il percorso di certificazione Oracle costava tra corsi
ed esami intorno ai 18.000 euro. Lo so in quanto avevo fatto una
valutazione.
Considerando cio' e considerando che e' molto difficile che si riesca
a fare ALTRO, chi ha quel tipo di qualifica ha tutto il diritto di
chiedere certe cifre.
Il problema non è tanto di quanto costi oracle in se o di quanto
costi uno specialista che ne risolve i casini. Il problema è fare una
SCELTA CONSAPEVOLE, non basata sul trafiletto letto sull'espresso o
sul cugggino che in azienda usa Oracle "che è una bomba".

Il cliente presso il quale era installato quel software (e quindi
Oracle) era il re delle scelte inconsapevoli. :)

Quella della scelta di quel software fu solo l'ultima di una lunga lista.

[a***@gmail.com]

On Monday, 9 February 2015 13:05:27 UTC, Alberto Salvati wrote:

[...]

Post by Alberto Salvati
Alcuni anni fa il percorso di certificazione Oracle costava tra corsi ed esami intorno ai 18.000 euro.

Non serve prendersi una certificazione da 18000 euro per lavorare con Oracle. Io ho lavorato con Oracle per anni e le parti piu` rognose di gestione del sistema se le smazzavano i DBA Oracle. E` chiaro che costavano un occhio della testa all'azienda, ma se hai un business tale da necessitare di Oracle, hai anche i soldi per i consulenti.

[Alberto Salvati]

Non parlavo di *usarlo*. Parlavo di fare il DBA..

[a***@gmail.com]

Post by Alberto Salvati
Non parlavo di *usarlo*. Parlavo di fare il DBA..

La certificazione come DBA varia nel costo. Diciottomila euro mi sembrano esagerati. Se mi dai dei riferimenti...

[Alberto Salvati]

Parliamo di circa 6 anni fa.

Non ho un link da passare. Appena ho tempo vado a verificare come stanno adesso le cose.
Avevo fatto il corso dba 1 (5 gg) su 9i pagandolo non poco.
Ricordo che il docente non era un "lettore di manuali" ma uno che faceva il DBA sul campo e ci fece molti esempi su casi reali che si era trovato a gestire.

Dopo qualche tempo mi arrivo' una mail con allegata una offerta per il set completo di corsi in aula e vouchers per gli esami e la cifra era grosso modo quella.
Ai tempi esisteva OCA, OCP e poi quella al top del quale mo non ricordo la sigla e l' offerta riguardava prp quella.

A.

[a***@gmail.com]

Post by Alberto Salvati
Ai tempi esisteva OCA, OCP e poi quella al top del quale mo non ricordo la sigla e l' offerta riguardava prp quella.

Stai probabilmente parlando della OCM, che e` una certificazione cha hanno in pochissimi e che tra i mortali non prende praticamente nessuno, anche perche` e` molto difficile da ottenere (richiede una prova sul campo abbastanza "tosta"). E` chiaro che per quella ti fanno pagare fiori di quattrini, ma non serve veramente se si vuol lavorare un DBA Oracle. I commerciali Oracle sono brutte bestie che ci provano sempre a tirarti in trappola; bisogna imparare a conoscerle e sceverare il bene dal male :)

[Alberto Salvati]

Post by a***@gmail.com
Stai probabilmente parlando della OCM

Azz..mi sa che è prp lei.

Post by a***@gmail.com
commerciali Oracle sono brutte bestie che ci provano sempre a tirarti

...bhe, fanno il loro lavoro.
Sta a chi sta dall'altre parte non farsi incantare.

A.

[a***@gmail.com]

Post by a***@gmail.com
"Sono riuscito ad evitare Oracle finora e spero di riuscire a farlo
anche in futuro." proprio perché so che è un motore di database
complesso da far girare al meglio. Richiede personale competente e
qualificato che, a volte, è assente perché, guarda caso, costa troppo.

Un'azienda seria, che si doti di Oracle, si dota anche del personale che serve a gestire quel sistema. Il problema non e` Oracle, e` chi decide di usare Oracle senza avere la minima idea di quali siano i requisiti per usarlo, quali siano le competenze di cui si ha bisogno per gestirlo, e quali siano i costi operativi.

[Morde]

Post by a***@gmail.com
Un'azienda seria, che si doti di Oracle, si dota anche del personale che serve a gestire quel sistema.

Francamente, ho lavorato in diverse PMI, e nessuna aveva un DBA: troppo
costoso metterlo a libro paga: meglio dissanguarsi in consulenze
puntuali quando il DB si corrompeva o dava problemi inattesi (si nota il
sarcasmo?)

Purtroppo noi siamo per la maggior parte dei self-made men, che hanno
imparato non solo a programmare, ma a fare anche i sistemisti, i DBA,
gli architetti del software, i consulenti, i managers di sè stessi.

[a***@gmail.com]

Post by Morde
Francamente, ho lavorato in diverse PMI, e nessuna aveva un DBA

Oracle non e` per le PMI. E` il discorso che facevo prima. Per usare Oracle, devi avere una struttura che lo supporti.

Post by Morde
Purtroppo noi siamo [...]

Noi chi?

[Massimo Soricetti]

Post by a***@gmail.com

Post by Morde
Purtroppo noi siamo [...]

Noi chi?

:-D

[Morde]

Post by a***@gmail.com

Post by Morde
Francamente, ho lavorato in diverse PMI, e nessuna aveva un DBA

Oracle non e` per le PMI. E` il discorso che facevo prima.

Non sono d'accordo: Oracle come tutti gli altri si è segmentata sul
mercato, e decidere di utilizzarlo per gestire i dati di una normale PMI
non mi sembra tanto sbagliato.

Oracle per le PMI:
http://www.oracle.com/it/solutions/midsize/overview/index.html

Post by a***@gmail.com
Noi chi?

Noi di ICLD.

[a***@gmail.com]

On Tuesday, 10 February 2015 13:42:08 UTC, Morde wrote:

[...]

Post by Morde
Non sono d'accordo: Oracle come tutti gli altri si è segmentata sul
mercato, e decidere di utilizzarlo per gestire i dati di una normale PMI
non mi sembra tanto sbagliato.

Il fatto che esistano soluzioni Oracle per PMI non significa che valga la pena usarle. Secondo me non ha senso puntare su Oracle quando esistono soluzioni migliori, a bassissimo costo o costo zero, che vanno benissimo per realta` non troppo complesse. Oracle, a mio parere, va scelto da una certa dimensione in su, e va scelto con molta cautela.

Post by Morde

Post by a***@gmail.com
Noi chi?

Noi di ICLD.

Ah ecco, "voi".

[Morde]

Post by a***@gmail.com

Post by Morde

Post by a***@gmail.com
Noi chi?

Noi di ICLD.

Ah ecco, "voi".

Non capisco.

[Warp10]

Post by a***@gmail.com

Post by a***@gmail.com
"Sono riuscito ad evitare Oracle finora e spero di riuscire a farlo
anche in futuro." proprio perché so che è un motore di database
complesso da far girare al meglio. Richiede personale competente e
qualificato che, a volte, è assente perché, guarda caso, costa troppo.

Un'azienda seria, che si doti di Oracle, si dota anche del personale
che serve a gestire quel sistema. Il problema non e` Oracle, e` chi
decide di usare Oracle senza avere la minima idea di quali siano i
requisiti per usarlo, quali siano le competenze di cui si ha bisogno
per gestirlo, e quali siano i costi operativi.

A titolo d'esempio ti posso dire che il cliente di cui parlo è talmente
serio che ha scelto il CMS col quale realizzare l'indecente sito che
mostra su Internet ad una fiera. La persona che lo ha scelto si stava
dimenticando d'essere andato a quella fiera per scegliere (anche) un CMS
ed ha preso una brochure al volo uscendo. Il CMS di quella brochure è
diventato il CMS col quale viene realizzato il sito.

Il cliente è una pubblica amministrazione.

[Morde]

On 09.02.2015 18:48, Warp10 wrote:>

Post by Warp10
Il cliente è una pubblica amministrazione.

Mi fa piacere sapere con quali criteri vengono prese certe decisioni,
soprattutto quando vengono finanziate con i soldi delle tasse dei
cittadini..

Meno male che ora vivo all'estero e le tasse non le pago più in Italia.

[Warp10]

Post by Morde
On 09.02.2015 18:48, Warp10 wrote:>

Post by Warp10
Il cliente è una pubblica amministrazione.

Mi fa piacere sapere con quali criteri vengono prese certe decisioni,
soprattutto quando vengono finanziate con i soldi delle tasse dei
cittadini..

Fosse solo quello.

Non esiste un elenco dei dipendenti.
Non esiste un elenco degli uffici.
Non esiste una tassonomia degli uffici (si sa che ci devono essere tre
livelli: direzione, servizio ed ufficio, ma non si sa quante direzioni
ci sono, da quanti servizi sono composte e quanti uffici compongono ogni
singola sezione).

[Alberto Salvati]

Post by Warp10
Ecco perché il fatto di averli o non averli a disposizione dovrebbe
essere una delle caratteristiche da prendere in considerazione per la
scelta del db da usare.

NI.....Si vive anche senza.

Post by Warp10
"su una grossa mole di" dati (presumo) tutto è pesante. :)

Su grosse mole di dati la join è quella che pesa di piu', seguita a ruota dagli ordinamenti.
Ho visto piu di un sistema con un alta percentuale di dati ridondanti prp per ridurre per quanto possibile il peso delle join.

Post by Warp10
Sono riuscito ad evitare Oracle finora e spero di riuscire a farlo anche
in futuro. Un mio cliente sta dismettendo un software, al quale un mio
software si sarebbe dovuto interfacciare, che si basava su Oracle.
Doveva essere scritto coi piedi perché non ho mai visto niente di più
bradipamente lento.

Oracle non è assolutamente "lento".
Se una app che usa Oracle è lenta alcuni dei motivi possono i seguenti:

1) applicazione scritta in modo cinofallico
2) database progettato in modo cinofallico
3) istanza oracle che gira su un sapientino
4) istanza oracle configurata in modo cinofallico
Quest'ultima speiga come mai un esperto oracle si GIUSTAMENTE pagare bene, visto che data la complessita', difficilmente puo fare altro.

Come qualsiasi prodotto, Oracle non va bene o male a prescindere.
Che poi io preferisca db2 è un altro discorso.


A.

[Warp10]

Post by Alberto Salvati

Post by Warp10
Sono riuscito ad evitare Oracle finora e spero di riuscire a farlo anche
in futuro. Un mio cliente sta dismettendo un software, al quale un mio
software si sarebbe dovuto interfacciare, che si basava su Oracle.
Doveva essere scritto coi piedi perché non ho mai visto niente di più
bradipamente lento.

Oracle non è assolutamente "lento".

E lo spero bene per lui.

Post by Alberto Salvati
1) applicazione scritta in modo cinofallico
2) database progettato in modo cinofallico
3) istanza oracle che gira su un sapientino
4) istanza oracle configurata in modo cinofallico

Mi sa che il software che ho visto io rispondeva "Esatto" a tutti e
quattro i punti. Anzi, forse ne avrebbe aggiunti un'altra decina circa,
uno peggio dell'altro, a sentire le considerazioni degli utenti. :)

Post by Alberto Salvati
Che poi io preferisca db2 è un altro discorso.

Fugace contatto tredici o quattordici anni fa.

[Morde]

On 09.02.2015 12:58

Post by Warp10

Post by Alberto Salvati
Oracle non è assolutamente "lento".

E lo spero bene per lui.

Forse non ti è chiaro che oggi, nel 2014, la potenza di calcolo a
disposizione dei database è enorme, al punto che una query anche
mastodontica viene eseguita in pochi millisecondi.

Quello che "rallenta" un'applicazione al punto da farti pensare che sia
colpa del database, può essere:

- database progettato in modo inefficiente
- query inefficienti (ed è responsabilità del client)
- infrastruttura inefficiente (reti fisiche e logiche)
- business logic inefficiente (programma che legge in sequenza la
testata, poi le righe, poi i dettagli, poi questo, puoi quello, senza
join, dati denormalizzati..)

Oggi è assurdo sentire affermare ancora qualcuno che sia il motore del
DB ad essere lento..

[a***@gmail.com]

On Monday, 9 February 2015 12:29:27 UTC, Morde wrote:

[...]

Post by Morde
Oggi è assurdo sentire affermare ancora qualcuno che sia il motore del
DB ad essere lento..

Sopratutto quando e` Oracle di cui si sta parlando.

[Warp10]

Post by Morde
On 09.02.2015 12:58

Post by Warp10

Post by Alberto Salvati
Oracle non è assolutamente "lento".

E lo spero bene per lui.

Quello che "rallenta" un'applicazione al punto da farti pensare che sia
- database progettato in modo inefficiente
- query inefficienti (ed è responsabilità del client)
- infrastruttura inefficiente (reti fisiche e logiche)
- business logic inefficiente (programma che legge in sequenza la
testata, poi le righe, poi i dettagli, poi questo, puoi quello, senza
join, dati denormalizzati..)

Come ho già scritto prima penso che il progettista di quel software
potrebbe aggiungere un'altra decina di punti a questo elenco. :)

Post by Morde
Oggi è assurdo sentire affermare ancora qualcuno che sia il motore del
DB ad essere lento..

Infatti io ho scritto
---
Sono riuscito ad evitare Oracle finora e spero di riuscire a farlo anche
in futuro. Un mio cliente sta dismettendo un software, al quale un mio
software si sarebbe dovuto interfacciare, che si basava su Oracle.
Doveva essere scritto coi piedi perché non ho mai visto niente di più
bradipamente lento.
---
Il "Doveva essere scritto coi piedi..." si riferiva al software e non ad
Oracle.

Ed il "E lo spero bene per lui." era ironico.

Se Oracle fosse stato la causa dei problemi di lentezza di quel software
non sarebbe mai diventato Oracle.

[a***@gmail.com]

Post by Warp10
Sono riuscito ad evitare Oracle finora e spero di riuscire a farlo anche
in futuro. Un mio cliente sta dismettendo un software, al quale un mio
software si sarebbe dovuto interfacciare, che si basava su Oracle.
Doveva essere scritto coi piedi perché non ho mai visto niente di più
bradipamente lento.

<...>

Post by Warp10
Se Oracle fosse stato la causa dei problemi di lentezza di quel software
non sarebbe mai diventato Oracle.

Interessanti queste due frasi dal punto di vista psicologico.

[Warp10]

Post by a***@gmail.com

Post by Warp10
Sono riuscito ad evitare Oracle finora e spero di riuscire a farlo anche
in futuro. Un mio cliente sta dismettendo un software, al quale un mio
software si sarebbe dovuto interfacciare, che si basava su Oracle.
Doveva essere scritto coi piedi perché non ho mai visto niente di più
bradipamente lento.

<...>

Post by Warp10
Se Oracle fosse stato la causa dei problemi di lentezza di quel software
non sarebbe mai diventato Oracle.

Interessanti queste due frasi dal punto di vista psicologico.

:)

[a***@gmail.com]

Post by Alberto Salvati
Nel caso delle fatture, dovresti quindi scrivere prima i record i testata e poi quelli di dettaglio.

Non e` propriamente uno svantaggio, ma un sistema per mantenere integrita` referenziale. Comunque le foreign keys (a seconda del database) si possono disabilitare. Il vero svantaggio per l'import/export sono semmai i trigger, che andrebbero sempre disabilitati.

Post by Alberto Salvati

Post by Warp10
1 - con una JOIN tramite due campi chiave (ID del cliente nella fattura
ed ID cliente nell'elenco clienti) faccio recuperare al database la
ragione sociale del cliente

Sbagliato. Concordo sui tuoi 1), 2) e 3), ma aggiungo che i dati che finiscono su documenti che hanno un valore contingente a quanto vengono prodotti vanno SEMPRE ridondati.

[Marco Breveglieri]

Post by Stark
pareva che proprio tu avessi scritto "Hai provato ad utilizzare i componenti
di FireDAC che sono "omonimi" (salvo il prefisso, ovviamente) di quelli del
BDE, tipo la TFDTable?".
Quindi ha pensato che FireDAC avesse qualcosa in più. Se non è così, cosa
volevi dire ?

FireDAC è del tutto differente da BDE, e ha molte cose in più: ti basta vedere uno dei tanti filmati segnalati su YouTube per averne una carrellata.

Detto questo, alcuni componenti di FireDAC hanno un nome del tutto simile alla controparte BDE proprio per semplificare la migrazione da quest'ultimo. Ciò non vuol dire che FireDAC sia il BDE con gli stessi componenti rinominati o che non abbia nulla in più: la semplificazione del passaggio dal BDE è una di queste, ma ci sono tantissimi altri componenti. E' più chiaro ora?

Post by Stark
Per il momento, nella mia mente ho scartato InterBase per quello che mi hai
detto tu, Firebird per quello che mi ha detto Laforgia e mi sono documentato
su SQLite, MySql e Postgres.

Bene.

Post by Stark
Per la conversione delle mie attuali applicazioni, sarei tentato da SQLite,
perchè mi appare il più semplice e risponde alle esigenze di queste
applicazioni. Ho però qualche dubbio che chi usa SQLite mi potrebbe
chiarire: Per esempio, non esiste un tipo di campo DATE, nè un tipo di campo
Memo. Come si fa con dati di questo tipo?

Prima di porre una domanda qui, prova a fare una ricerca: io non uso abitualmente SQLite, però con un semplice passaggio su Google ho ottenuto una risposta in pochi secondi; leggi qui, ad esempio:
https://www.sqlite.org/datatype3.html

Post by Stark
Non risolvo il problema delle TTable, usate abbastanza estensivamente.

Che problema?

Post by Stark
Problema che comunque avrei anche con MySql e Postgres.

Per forza, perché i componenti FireDAC sono gli stessi, a prescindere dal database, dato che *non* sono appunto un database. Non avevi già superato questo punto? :)

Post by Stark
La conversione a FireDAC/SQLite potrebbe rivelarsi eccessivamente pesante
rispetto al vantaggio di abbandonare una tecnologia obsoleta, ma ancora
perfettamente funzionante?

Senz'altro ha un suo costo. Poi quale sia è difficile dirlo, perché dipende da
1) quali componenti hai usato,
2) come li hai usati,
3) come hai strutturato la tua applicazione,
4) quali sono le tue competenze.

Post by Stark
Non lo so, non mi pare di avere ancora abbastanza elementi per decidere.

Senz'altro abbandonare una libreria deprecata dal 2001 è una buona idea, però onestamente mi è sfuggita la "scintilla" che ti ha spinto a fare questa migrazione ora.

Solo per usare XE7?

Se XE7 ti fornisce delle feature imprescindibili per il tuo software (ad esempio, vuoi portarlo su 64 bit, o su altre piattaforme), allora è uno scoglio necessario, dato che il BDE è stato (finalmente) rimosso da XE7, altrimenti se non hai questa esigenza, puoi rimanere su una versione appena precedente di Delphi e compiere questa migrazione con più calma, gradualmente, pezzo per pezzo.

Altri consigli non saprei darteli perché non so quali sono i tuoi "margini di manovra" e solo tu puoi sapere l'impatto e il vantaggio di determinate scelte che sono del tutto personali.

Ciao,
Marco.

[Stark]

Post by Stark
Non risolvo il problema delle TTable, usate abbastanza estensivamente.

Che problema?
Senz'altro abbandonare una libreria deprecata dal 2001 è una buona idea,
però onestamente mi è sfuggita la "scintilla" che ti ha spinto a fare questa
migrazione ora.
Solo per usare XE7?
Se XE7 ti fornisce delle feature imprescindibili per il tuo software (ad
esempio, vuoi portarlo su 64 bit, o su altre piattaforme), allora è uno
scoglio necessario, dato che il BDE è stato (finalmente) rimosso da XE7,
altrimenti se non hai questa esigenza, puoi rimanere su una versione appena
precedente di Delphi e compiere questa migrazione con più calma,
gradualmente, pezzo per pezzo.
Ciao,
Marco.
Quando pensavo alle TTable come un problema, mi riferivo alla necessità di
rimaneggiare i programmi per sostituirle con delle Query: Le ho usate spesso
con filtri e con le relazioni Master Detail.
E si, migrerei per poter usare XE7, non tanto perchè abbia delle features
imprescindibili, ma perchè l'assenza del BDE mi ha fatto pensare al futuro e
potrei prendere l'occasione. Certo lo farei con gradualità ...
Grazie comunque per i consigli preziosi !


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
http://www.avast.com

[a***@gmail.com]

Post by Stark
applicazioni. Ho però qualche dubbio che chi usa SQLite mi potrebbe
chiarire: Per esempio, non esiste un tipo di campo DATE, nè un tipo di campo
Memo. Come si fa con dati di questo tipo?

Leggere no, eh? :)

https://www.sqlite.org/datatype3.html
https://www.sqlite.org/lang_datefunc.html

[Stark]

Post by Stark
applicazioni. Ho però qualche dubbio che chi usa SQLite mi potrebbe
chiarire: Per esempio, non esiste un tipo di campo DATE, nè un tipo di campo
Memo. Come si fa con dati di questo tipo?

Leggere no, eh? :)
https://www.sqlite.org/datatype3.html
https://www.sqlite.org/lang_datefunc.html

Grazie del link, ma lì vengono descritte le funzioni Date and Time. Ma sul
record, che tipo si definisce per una data ?


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
http://www.avast.com

[a***@gmail.com]

On Tuesday, 10 February 2015 09:23:00 UTC, Stark wrote:

[...]

Grazie del link, ma lě vengono descritte le funzioni Date and Time. Ma sul
record, che tipo si definisce per una data ?

Ho capito, sei un troll.

[Massimo Soricetti]

Post by a***@gmail.com
Ho capito, sei un troll.

:-D

[a***@gmail.com]

non sviluppo applicazioni mutliutente o Client Server, ma applicazioni
monoutente, con volumi di transazioni e necessità di archiviazione limitata, in ambiente Windows.

A questo punto potresti usare anche un semplice file Access, con accesso ADO. Funziona benissimo per esigenze come le tue. Non ti serve un database C/S, con tutto il peso di un'installazione.

[Alberto Salvati]

Ancora prima di pensare al db sul quale ti hanno gia' dato dei suggerimenti, ti suggerisco di riflettere molto bene e fare una accurata analisi dell'impatto sulla tua applicazione di un cosi' radicale cambiamento, sopratutto per quanto riguarda il tipo di oggetto di accesso ai dati che usi materialmente-
Se usi bde, presumo che utilizzando database fileserver come dbase o paradox, usi oggetti "tabella" come TTable.

In genere sui db client/server si usano oggetti "query" (TSqlQuery, TAdoQUery, TFDQuery..) che funzionano su una filosofia di base diversa.
Quindi, ancora prima di pensare al db sul quale ti hanno gia' dato indicazioni, ti suggerisco di riflettere molto bene e fare una accurata analisi dell'impatto sulla tua applicazione di un cosi' radicale cambiamento,

A.

[Stark]

"Alberto Salvati" ha scritto nel messaggio news:d369d579-6cc3-48f9-8dc6-***@googlegroups.com...
Quindi, ancora prima di pensare al db sul quale ti hanno gia' dato
indicazioni, ti suggerisco di riflettere molto bene e fare una accurata
analisi dell'impatto sulla tua applicazione di un cosi' radicale
cambiamento,
A.
La tua riflessione è giusta, ma mi soprende. La mia decisione è maturata
anche perchè installando XE7 non ho più trovato il BDE. Quindi sarei per
sempre legato alla versione 2007 che utilizzo oggi. E poi leggo
continuamente incoraggiamenti ad abbandonarlo questo BDE e questo dBase.
Poichè, come ho cercato di spiegare nel mio primo post, le mie esigenze sono
elementari (applicazioni monoutente, no architetture multi tier, volumi di
transazioni e di storage limitati), pensavo che anche la trasformazione
potesse essere più facile. Si, adesso lavoro con TTable e TQuery. Non c'è un
ambiente analogo ?


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
http://www.avast.com

[a***@gmail.com]

potesse essere piů facile. Si, adesso lavoro con TTable e TQuery. Non c'č un
ambiente analogo ?

Usa ADO + Access.

[Morde]

Post by Stark
Poichè, come ho cercato di spiegare nel mio primo post, le mie esigenze
sono elementari (applicazioni monoutente, no architetture multi tier,
volumi di transazioni e di storage limitati), pensavo che anche la
trasformazione potesse essere più facile.

Parlando di scelta di database, se vuoi un giusto compromesso tra
leggerezza e usabilità, ti consiglio Firebird. Andrea suggerisce Access,
ma lo devi aver comprato e ci si interfaccia via ado, tuttavia dici di
usare tquery e compagnia bella.

Vantaggi passando a firebird:
gratuito
maturo
ben supportato dalla community

Svantaggi:
mancanza quasi totale di tools gratuiti
mancanza di letteratura (libri blogs e tutorial)
se devi fare operazioni complicate (upgrade di versioni, riparazione db
corrotto) la cosa diventa assai complicata!

Pondera bene le tue scelte.
Se hai domande specifiche su firebird, chiedi pure.

[a***@gmail.com]

Post by Morde
Parlando di scelta di database, se vuoi un giusto compromesso tra
leggerezza e usabilità, ti consiglio Firebird.

Ma va. A questo punto, molto meglio PostgreSQL.

[Morde]

Post by a***@gmail.com
Ma va. A questo punto, molto meglio PostgreSQL.

Il prossimo database che vorrei usare per un nuovo progetto è proprio
PostgreSQL, ma per mia curiosità personale, per impararlo, e perchè
tutti me ne parlano bene.

Tuttavia per i requisiti dell'OP penso che sia overkill, in fin dei
conti con firebird rendi un programma portabile con due soli file:
fbclient.dll e il database stesso *.fdb

[a***@gmail.com]

Post by Morde
Tuttavia per i requisiti dell'OP penso che sia overkill, in fin dei
fbclient.dll e il database stesso *.fdb

Si`, ma siamo sempre al solito problema: perche` usare una tecnologia di nicchia (Firebird) quando se ne puo` usare una piu` conosciuta, piu` testata (e quindi piu` affidabile), tecnicamente di gran lunga migliore, con piu` (e migliore) documentazione, piu` supporto disponibile in giro (Postgres)?
Personalmente, mi sono scottato con Firebird molti anni fa, quando ci avevo basato sopra un intero sistema e, per stranissime ragioni, la comunicazione col server falliva regolarmente, in determinati casi. Il debugging era praticamente impossibile, la ragione del problema misteriosa ancora dopo giorni e notti di lavoro; decisione drastica del team: passare a Postgres. Migrato il sistema, senza cambiare una riga di codice Delphi (era basato su ClientDataSet/DataSetProvider), a parte quelle direttamente legate all'accesso dati, il problema e` sparito. Non riuserei Firebird neanche se mi dessero dei soldi.

[Morde]

Post by a***@gmail.com
Si`, ma siamo sempre al solito problema: perche` usare una tecnologia di nicchia (Firebird)
quando se ne puo` usare una piu` conosciuta, piu` testata (e quindi

piu` affidabile),

Post by a***@gmail.com
tecnicamente di gran lunga migliore, con piu` (e migliore)

documentazione,

Post by a***@gmail.com
piu` supporto disponibile in giro (Postgres)?

Effettivamente..

Post by a***@gmail.com
Personalmente, mi sono scottato con Firebird molti anni fa, quando ci avevo basato sopra un intero sistema [...]

Capisco la situazione, perchè ho pagato uno scotto simile: ho usato
C++/Qt con firebird per un progetto di lunga durata: considerando il mio
know-how e la mia esperienza, me la sono sempre cavata.

Un giorno, tuttavia, ho upgradato l'API di Qt (4.8->5.3), e di colpo
tutte le letture di orari fatti sul db, leggevano il valore 0.

Per farla breve: il driver Qt per il DB interbase, col passaggio alla
major release, ha smesso di leggere i timestamp correttamente.
Ho risolto scaricando i sorgenti Qt, ricompilandomi il driver interbase,
debuggandolo e fixandolo.

Quando ho aperto il bug sul bug-tracker di Qt, mi sono accorto che,
probabilmente, io ero l'unico sviluppatore che utilizzasse Qt insieme a
Firebird: un bug di questo tipo è bloccante,ma nessuno prima di me aveva
segnalato la cosa..

E' chiaro che è un caso limite: ma avendolo provato sulla mia pelle, non
posso che ammettere che firebird risulta essere più limitante di altri
DB molto più diffusi.

[a***@gmail.com]

On Friday, 6 February 2015 13:46:56 UTC, Morde wrote:

[...]

Post by Morde
Quando ho aperto il bug sul bug-tracker di Qt, mi sono accorto che,
probabilmente, io ero l'unico sviluppatore che utilizzasse Qt insieme a
Firebird

E` cosi` con tutto cio` che e` di nicchia, non diffuso, non conosciuto, non usato. Bisogna stare molto attenti, perche` si rischia di ficcarsi in vicoli ciechi. Tempo fa c'erano dei driver dbExpress per Postgres che non funzionavano granche` bene (con i blob, in particolare). Bug che nessuno ha mai risolto perche` non c'era poi una cosi` grande esigenza. Vorrei vedere, d'altronde, chi e` che comprerebbe un'automobile, sapendo a priori che non trovera` facilmente pezzi di ricambio sul mercato.

[Warp10]

Post by Morde
mancanza quasi totale di tools gratuiti

Flamerobin (gratuito) fa il suo dovere per la creazione e la gestione
dei database ed è anche multipiattaforma.

Non è grafico, ma questo è un vantaggio. :)

Post by Morde
mancanza di letteratura (libri blogs e tutorial)

Finora ho trovato tutto quello che mi serviva. La sintassi delle query
è, ovviamente, SQL e quindi esempi scritti in SQL (abbastanza) standard
per altri db si possono adattare senza tanti problemi.

Post by Morde
se devi fare operazioni complicate (upgrade di versioni, riparazione db
corrotto) la cosa diventa assai complicata!

Per l'upgrade da FB1.5 a FB2.5 ho fatto un backup del db tramite FB1.5
ed un restore tramite FB2.5.

FB1.5 e FB2.5 installati sulla stessa macchina e switch da uno all'altro
tramite questi file batch:

- Da 1.5 a 2.5 ---
REM Shut down & remove the Firebird 1.5 service
"C:\Program Files (x86)\Firebird\Firebird_1_5\bin\instsvc" stop
"C:\Program Files (x86)\Firebird\Firebird_1_5\bin\instsvc" remove

REM Update the registry entry to reflect FB2 install
"C:\Program Files\Firebird\Firebird_2_5\bin\instreg.exe" install

REM Install & start the Firebird 2 Service (with guardian)
"C:\Program Files\Firebird\Firebird_2_5\bin\instsvc" install -g
"C:\Program Files\Firebird\Firebird_2_5\bin\instsvc" start
---

- Da 2.5 a 1.5 ---
REM Shut down & remove the Firebird 2 service
"C:\Program Files\Firebird\Firebird_2_5\bin\instsvc" stop
"C:\Program Files\Firebird\Firebird_2_5\bin\instsvc" remove

REM Update the registry entry to reflect FB1.5 install
"C:\Program Files (x86)\Firebird\Firebird_1_5\bin\instreg.exe" install

REM Install & start the Firebird 1.5 Service (with guardian)
"C:\Program Files (x86)\Firebird\Firebird_1_5\bin\instsvc" install -g
"C:\Program Files (x86)\Firebird\Firebird_1_5\bin\instsvc" start
---
L'unica pecca è che non si possono avere attivi contemporaneamente
entrambi i motori. O usi l'uno o usi l'altro.

Per la corruzione dei dati non so dare indicazioni in quanto non mi è
mai capitata l'occasione (fortunatamente :) ), ma penso sia
un'operazione tutt'altro che indolore con qualunque engine.

[Morde]

Post by Warp10
Flamerobin (gratuito) fa il suo dovere per la creazione e la gestione
dei database ed è anche multipiattaforma.
Non è grafico, ma questo è un vantaggio. :)

Come non è grafico? Nel senso che ci scrivi SQL a mano, forse.
Io lo uso ogni giorno e non ho problemi, ma come ti dicevo, ce ne sono
altri migliori a pagamento, ad esempio EMS SQL manager.

Post by Warp10
Finora ho trovato tutto quello che mi serviva. La sintassi delle query
è, ovviamente, SQL e quindi esempi scritti in SQL (abbastanza) standard
per altri db si possono adattare senza tanti problemi.

Se vuoi scrivere stored procedures, non esiste un tool free che ti
faccia il debug (a meno che tu non voglia scriverti dei log...)
L'API è documentata al minimo, stringata, spesso ridotta solo alla
spiegazione canonica del comando.
Esiste un unico libro che spiega l'architettura e come lavora Firebird:
http://www.firebirdsql.org/en/books/

Per tutti gli altri database, ne trovi a decine...

Post by Warp10
Per l'upgrade da FB1.5 a FB2.5 ho fatto un backup del db tramite FB1.5
ed un restore tramite FB2.5.

Io per un semplice upgrade dalla 2.1 alla 2.5, mi sono trovato un
bell'errore sui dati, e me lo sono dovuto smazzare per ore.
Ho dovuto lavorare con gfix e gbak, dopo parecchi try-error

Per farla breve, se tutto va bene, basta far girare un batch come quello
da te quotato.
Ma al primo problema, il supporto disponibile tra documentazione, rete e
libri, è pressochè zero.

[Warp10]

Post by Morde

Post by Warp10
Flamerobin (gratuito) fa il suo dovere per la creazione e la gestione
dei database ed è anche multipiattaforma.
Non è grafico, ma questo è un vantaggio. :)

Come non è grafico? Nel senso che ci scrivi SQL a mano, forse.

Esatto.

Con "grafico" intendevo che non ti fa vedere le eventuali relazioni tra
tabelle come invece altri strumenti, tipo DBeaver, fanno.

Post by Morde
Io lo uso ogni giorno e non ho problemi, ma come ti dicevo, ce ne sono
altri migliori a pagamento, ad esempio EMS SQL manager.

Lo so, ma è la parte "a pagamento" che mi blocca. :)

Post by Morde

Post by Warp10
Finora ho trovato tutto quello che mi serviva. La sintassi delle query
è, ovviamente, SQL e quindi esempi scritti in SQL (abbastanza) standard
per altri db si possono adattare senza tanti problemi.

Se vuoi scrivere stored procedures, non esiste un tool free che ti
faccia il debug (a meno che tu non voglia scriverti dei log...)

Vero.

Post by Morde

Post by Warp10
Per l'upgrade da FB1.5 a FB2.5 ho fatto un backup del db tramite FB1.5
ed un restore tramite FB2.5.

Io per un semplice upgrade dalla 2.1 alla 2.5, mi sono trovato un
bell'errore sui dati, e me lo sono dovuto smazzare per ore.
Ho dovuto lavorare con gfix e gbak, dopo parecchi try-error

Devo ritenermi fortunato, allora. :)

Post by Morde
Per farla breve, se tutto va bene, basta far girare un batch come quello
da te quotato.

I due batch servono solo per passare da un motore all'altro. La sequenza
che ho fatto è stata:
1 - lancio FlameRobin
2 - backup da FB1.5
3 - esco da FlameRobin
4 - batch da FB1.5 a FB2.5
5 - lancio FlameRobin
6 - restore in FB2.5

[giovanni.v]

Le mie esigenze non sono particolarmente sofisticate, perchè
l'applicazione è stand alone, monoutente e i volumi sono dell'ordine di
poche decine di migliaia di records. Vorrei che la installazione
dell'applicazione non esigesse dei prerequisiti e infine non vorrei
spendere altri soldi.

SQLite per applicazioni monoutente va benissimo, è leggerissimo ed hai a
disposizione un set di istruzioni sql che non ti creerà grossi problemi
anche a scalare in futuro verso altri db engine client-server.
Provato recentemente anche con il db dei cap (completo) la risposta alle
ricerche è veramente eccellente.

Il deploy è ancor più semplice che FB embedded (comunque ottima scelta)
esendo sufficiente distribuire una dll (sqlite3.dll).

[a***@gmail.com]

Post by giovanni.v
SQLite

Ottima alternativa.

Post by giovanni.v
Il deploy è ancor più semplice che FB embedded (comunque ottima scelta)
esendo sufficiente distribuire una dll (sqlite3.dll).

Se puo` interessare, anche per MySQL esiste una versione Embedded (usata e va abbastanza bene).

[giovanni.v]

Post by a***@gmail.com
Se puo` interessare, anche per MySQL esiste una versione Embedded (usata e va abbastanza bene).

MySQL emb. e Firebird emb. sono enormemente più esigenti di SQLite in
termini di risorse (cpu/memoria) quindi come sempre molto dipende da
cosa si vuole fare... per dire una cattiveria se ancora oggi c'è chi usa
access per fare gestionali allora lo stesso si può fare con sqlite ;-) e
con qualche attenzione si può fare anche l'accesso condiviso.

Se interessa anche la portatilità, sempre parlando di embedded e
considerando l'architettura cpu non il sist. operativo, allora mentre
MySQL ed SQLite sono cross-platform Firebird non lo è.

Attenzione anche al fatto che il licensing di MySQL è piuttosto
complesso e tutt'altro che di libero uso nel caso di applicazioni
commerciali.
L'alternativa praticamente drop-in è MariaDB.

[a***@gmail.com]

Post by giovanni.v
MySQL emb. e Firebird emb. sono enormemente più esigenti di SQLite in
termini di risorse (cpu/memoria)

Bah... coi sistemi di oggi questo problema non si pone neanche. Io ho usato MySQL Embedded gia` anni fa, e andava come una bomba (in senso positivo).

Post by giovanni.v
per dire una cattiveria se ancora oggi c'è chi usa
access per fare gestionali allora lo stesso si può fare con sqlite ;-)

Cattiveria verso chi? Access e` sempre stato (e lo e` ancora) perfettamente valido per esigenze come quelle di Stark. Come detto, SQLite e` un'ottima alternativa.

[Warp10]

Post by giovanni.v
MySQL ed SQLite sono cross-platform Firebird non lo è.

Linux e Windows non bastano?

http://www.firebirdsql.org/en/about-firebird/

:)

[giovanni.v]

Post by Warp10

Post by giovanni.v
MySQL ed SQLite sono cross-platform Firebird non lo è.

Linux e Windows non bastano?

Non mi riferivo al solo sistema operativo e comunque ero rimasto
indietro: sono convinto che fino a qualche tempo fà la versione embedded
non fosse utilizzabile su linux, ho ricontrollato e nella faq della 2.5
affermano che la "superserver" può essere utilizzata come embedded.
Medesimo errore per l'architettura, ergo io non l'ho mai detto ;-)

[Warp10]

Post by giovanni.v

Post by Warp10

Post by giovanni.v
MySQL ed SQLite sono cross-platform Firebird non lo è.

Linux e Windows non bastano?

Non mi riferivo al solo sistema operativo e comunque ero rimasto
indietro: sono convinto che fino a qualche tempo fà la versione embedded
non fosse utilizzabile su linux, ho ricontrollato e nella faq della 2.5
affermano che la "superserver" può essere utilizzata come embedded.
Medesimo errore per l'architettura, ergo io non l'ho mai detto ;-)

Detto cosa, scusa? ;-)

[a***@gmail.com]

Post by Warp10
Linux e Windows non bastano?

Se ci fosse anche Max OSX sarebbe meglio. Lo supporta? Il sito menziona solo "a variety of Unix platforms."

[Warp10]

Post by a***@gmail.com

Post by Warp10
Linux e Windows non bastano?

Se ci fosse anche Max OSX sarebbe meglio. Lo supporta? Il sito menziona solo "a variety of Unix platforms."

http://www.firebirdsql.org/en/downloads/

---
Supported Platforms

Firebird 2.5 runs on Windows (32- and 64-bit), various Linux versions
(32- and 64- bit), Solaris (Sparc and Intel), HP-UX (PA-Risc) and MacOS
X. Main development is done on Windows and Linux, so new releases are
usually offered first for these platforms, followed by other platforms
after a few weeks.
---