Sviluppo applicazione con D2011 XE e scelta DB
alessandro f
Sto iniziando lo sviluppo di applicazioni con Delphi 2011 (sono alle
prime armi) e devo valutare quale DB utilizzare e quale "tecnologia"
per l'accesso al DB (considerando tool che supporteranno i 64bit)
ho letto in giro di varie possiblità tra MS SQL , MYSQL , FIREBIRD etc
e i vari ADO , dbexpress e "terze parti" gratuite e no
sono un po confuso in quanto non riesco a fare una valutazione
chiara , volevo chiedere qualche consiglio agli esperti che hanno già
sviluppato gestionali con Delphi
l'applicazione dovrebbe gestire in rete un DB che arriva a massimo
10000 record per anno , stavo pensando di separare il DB uno per ogni
anno per semplificare la gestione dei dati vecchi
ho la necessità di creare un tool di visualizzazione/scorrimento dei
dati per l'utente finale dove , con varie selezioni, poter
visualizzare solo una parte dei record e su questi poter effettuare
direttamente modifiche , cancellazioni e duplicazioni
attualmente ho un programma che fa questo e che ha un tool di
visualizzazione avanzato che scorre i record "in tempo" reale , cioè ,
nel caso di installazione in rete , se un utente inserisce o aggiorna
da altra postazione un nuovo record e questo rientra nella query di
ricerca dell'utente che sta scorrendo i record, quest'ultimo se lo
ritrova direttamente nel suo "scorrimento" appena preme un tasto (up,
down)
vorrei chiedere consigli su quale DB dirigermi e con quale tipo di
accesso
in generale se ho capito bene dbexpress rende indipendenti dal DB ma
richiede l'acquisto di una licenza più costosa di Delphi
mi sono state suggerite soluzioni del tipo MYSQL , ma sostanzialmente
la mia applicazione non sarà weboriented. sono anche un po scettico su
MYSQL che è gratuito ma non lo è in realtà quando si vende una
applicazione a terzi (se ho capito bene)
oppure MS SQL express che è gratuito fino a 5 postazioni (dovrebbero
bastare salvo qualche caso raro)
trovandomi a sviluppare ex novo stavo pensando di evitare di
utilizzare ADO (o altri tool terzi gratuiti e non) x evitare in un
prossimo futuro di dover "correggere e portare" verso dbexpress
in ogni caso considerando la capacità della tecnologia/db di
scorrimento dei record
so che ci sono anche molti tools di terze parti (gratuiti e non )ma
bisognerebbe avere esperienza in merito per poterli valutare
grazie per gli eventuali consigli
saluti
Alessandro
Warp10
Forse pi� Zeos che IBX cos� ti sleghi dal motore db.
Database : Firebird
Pro:
- Gratuito per tutte i tipi di programmi che vuoi creare
- Di facilissima manutenzione
- Multipiattaforma (il server pu� anche essere Linux il che ha i suoi
vantaggi)
- Leggero e veloce (almeno per le necessit� che hai descritto)
- � client/server (niente directory condivise, basta conoscere l'IP del
server dove gira il servizio di FB e l'alias assegnato al db o, in
alternativa, il suo percorso)
- Buona documentazione
Contro:
- Un client installato su ogni PC che si connette (non � un "contro" ma
� una necessit�)
- � client/server (devi studiarti le transazioni altrimenti il prossimo
messaggio che posti sar� "Come mai il client X non vede quello che salva
il client Y?" :) )
- Dovrai sostenere inutili discussioni con quelli che continueranno a
dirti "Ma come?! Non usi XXXSiquel?! Ma � meraviglioso, potentissimo,
ultrafighissimo, stravelocissimo, va bene anche per le uebapplicascions"
(a me capita ad ogni nuovo progetto e quelli che m'hanno detto la frase
si ricredono sempre alla fine)
Se non si fosse capito uso FB + IBX/Zeos da tempo e non ho mai avuto
ragione di cambiare.
Luigi Siciliano
> Accesso dati : IBX/Zeos
> Se non si fosse capito uso FB + IBX/Zeos da tempo e non ho mai avuto
> ragione di cambiare.
>
Usi la versione unicode?
Se posso, come ti trovi?
la trovi abbastanza affidabile per la produzione?
Io sto usando la 6.6.6 ma con D5
Grazie, ciao.
morde
> - � client/server (devi studiarti le transazioni altrimenti il prossimo
> messaggio che posti sar� "Come mai il client X non vede quello che salva
> il client Y?" :) )
Questo mi interessa: stai dicendo che con zeos c'� un meccanismo di
obesrving che mostra i dati live proprio come il caso proposto dall'OP ?
Cio�, mentre scorro il dataset, se un altro client aggiunge un record,
me lo ritrovo automaticamente nella mia griglia ?
Con l'adodataset per vedere il record aggiunto bisognava farsi un "refresh".
--
morde
QT 4.7
Delphi (5,6,7.. expired)
Firebird Database
Warp10
Zeos o IBX c'entrano poco.
Ci� che pu� rendere immediata la visualizzazione della modifica operata
ad una tabella dopo il Commit (o il CommiRetaining) � il sistema di
eventi di Firebird.
L'applicazione rimane in ascolto di questi eventi tramite un componente
(negli IBX c'� TIBevents) e quando arriva l'evento opera le azioni
richieste.
Warp10
> Il 13/10/2011 11.40, Warp10 ha scritto:
>> Accesso dati : IBX/Zeos
>> Se non si fosse capito uso FB + IBX/Zeos da tempo e non ho mai avuto
>> ragione di cambiare.
>>
>
> Usi la versione unicode?
No.
> Io sto usando la 6.6.6 ma con D5
Io l'ho usata con D7 per un mio personale software di conversione
archivi Access -> FB visto che ero stufo di scrivere un software apposta
per ogni conversione.
L'ho fatto pi� per curiosit� che per vera necessit� e prima o poi
compir� il grande passo di sostituire i componenti IBX con Zeos in tutti
i miei progetti.
Per ora vale ancora il detto "se funziona non toccare". :)
Warp10
> l'applicazione dovrebbe gestire in rete un DB che arriva a massimo
> 10000 record per anno , stavo pensando di separare il DB uno per ogni
> anno per semplificare la gestione dei dati vecchi
Questo dipende da cosa ci sar� negli archivi dei singoli anni.
Non si pu� dare un consiglio in un senso o nell'altro.
Io ho iniziato un progetto nel 1997 (peccato di giovent� :) ) dividendo
gli archivi per anni ed ora sto pensando di riunire tutti gli archivi in
un unico db. In tutti i progetti nuovi, memore dell'errore, parto sempre
con un unico db e divido gli anni all'interno del db segnando
l'appartenenza dei vari record all'anno (fatture, movimenti,
rottamazioni ecc...).
Per farti un esempio legato al progetto del 1997 io identifico ogni
materiale con un ID automatico generato da FB. Nei vari anni lo stesso
ID pu� fare riferimento a materiali diversi perch�, nel periodo di
passaggio, vengono creati nuovi materiali sia nell'anno precedente sia
in quello attuale. Il programma opera solo in un anno alla volta e
quindi non ci sono problemi ma � un problema al quale devo porre rimedio
per poter unire tutto insieme.
Tieni conto, poi, che se vuoi far usare pi� ambienti (come capiter�
senz'altro) dovrai memorizzare da qualche parte (TXT, INI, altro db,...)
i percorsi (o gli alias). Usando un solo db, invece, hai un unico
percorso (o alias) e puoi far gestire l'anno pi� semplicemente. Inoltre
fai il backup di un solo db.
morde
> L'applicazione rimane in ascolto di questi eventi tramite un componente
> (negli IBX c'� TIBevents) e quando arriva l'evento opera le azioni
> richieste.
Ok ho capito: � proprio quello che voglio fare anche io per il mio
programma in qt.
http://www.firebirdsql.org/file/documentation/papers_presentations/Power_Firebird_events.pdf
Alberto Salvati
XE2....! :-D
Il primo step riguarda capire se vuoi mettere mano al portafogli o no.
Potendo spendere, scarterei SqlServer:
1) gira solo su winzozz
2) gira solo su versioni winzozz SERVER
Per la mode di dati che hai al momento, andare su oracle non esiste.
Da valutare sarebbero Sybase e Db2 che a partire dalla versione 9 ha
semplificato parecchio la parte di gestione e configurazione rendendo
automatiche parecchie cose. Cmq, per entrambi XE2 dovrebbe se non erro
includere i driver dbx.
Se non vuoi e/o puoi mettere mano alla tasca scarterei MySql per i
problemi legati alla licenza da te stesso citati.
Firebird e' un po che non lo uso.
Ultimamente un db che fa parlare parecchio di se e' postgres.
Ti suggerisco di fare un cfr tra i due prodotti.
Riguardo l'accesso ai dati, potendo scappare da ADO lo farei IERI.
Qua usiamo ADO su xp, seven, windows server, sia su 32 che 64 bit..
Non o dati oggettivi ma la sensazione e' che ogni tanto qualcosa vada
ai festini del nano di arcore.
Cmq, alle tue info mancano un pezzo.. Va bene 10.000 record, ma.....
1) per QUANTI UTENTI? 2, 10, 500...?
2) non e' che i 10.000 record arrivano tutti nell'arco di 2 minuti??
> 10000 record per anno , stavo pensando di separare il DB uno per ogni
> anno per semplificare la gestione dei dati vecchi
Esatto di Esa Software lavora(va) cosi'...
E puntualmente l'utente imprecava in quanto costretto a uscire-
rientrare-uscire-rientrare ogni volta che doveva consultare i dati
dell'anno precedente...
> in generale se ho capito bene dbexpress rende indipendenti dal DB ma
> richiede l'acquisto di una licenza più costosa di Delphi
Questa cosa e' vera in parte.
Se hai la stessa struttura di tabelle e stored procedure che hanno gli
stessi parametri anche se il codice sorgente e' diverso, SI.
Ma va detto che non tutti i db sono uguali...
Oracle, Db2 e Firebird hanno sequences/generators, ma SqlServer di
certo fino a qualche versione fa questa cosa non l'aveva...
Ergo, se hai una stored procedure su un db Oracle che usa una
sequence, per spostarla su SqlServer dovrai inventarti TU qualcosa per
calcolarti un ID...
Generalizzando, l'accesso ai dati e' solo un pezzo.
Anche la applicazione dovrebbe eve essere *pensata*, progettata e
scritta per essere indipendente dal db.
Questa cosa si chiama MDA (Model Driver Architecture).
A.
Alberto Salvati
A.
Gello Ramello
>
> ho letto in giro di varie possiblitￜ tra MS SQL , MYSQL , FIREBIRD etc
> e i vari ADO , dbexpress e "terze parti" gratuite e no
>
venga preso in considerazione Postgresql (o Postgres).
Ha una potenza paragonabile a Oracle, gira su Windows e su Linux, ha
una comunitￜ molto attiva (vedi versione 9.1 che ha cose strabilianti)
ed ￜ completamente gratuito.
--
Trasformare i sudditi in cittadini ￜ miracolo che solo la scuola puￜ
compiere. (Piero Calamandrei)
Marco Breveglieri
> Salve a tutti, mi inserisco perchￜ non riesco proprio a capire come non
> venga preso in considerazione Postgresql (o Postgres).
Per il tipo di applicazione che è stato indicato, ci si può stupire di qualsiasi database non venga citato, data la genericità della richiesta. :)
--
Marco Breveglieri
(http://www.marco.breveglieri.name)
morde
> Ha una potenza paragonabile a Oracle, gira su Windows e su Linux, ha una
> comunitￜ molto attiva (vedi versione 9.1 che ha cose strabilianti) ed ￜ
> completamente gratuito.
Sono interessato a postgres: hai qualche link di
risorse/community/gruppi in italiano ?
Gello Ramello
> On 13.10.2011 14:38, Gello Ramello wrote:
>> Ha una potenza paragonabile a Oracle, gira su Windows e su Linux, ha una
>> comunitￜ molto attiva (vedi versione 9.1 che ha cose strabilianti) ed ￜ
>> completamente gratuito.
>
> Sono interessato a postgres: hai qualche link di risorse/community/gruppi in
> italiano ?
Non ho link a risorse in italiano. In genere la documentazione e
qualche forum come stackoverflow ecc. mi sono sufficienti a risolvere i
problemi, ma sono in inglese.
Warp10
> Il giorno gioved� 13 ottobre 2011 14:38:55 UTC+2, Gello Ramello ha scritto:
>> Salve a tutti, mi inserisco perchￜ non riesco proprio a capire come non
>> venga preso in considerazione Postgresql (o Postgres).
>
>
Tu dici che non si possono escludere nemmeno dbIII, dbIV e FileMaker? :)
Gello Ramello
> Il giorno giovedￜ 13 ottobre 2011 14:38:55 UTC+2, Gello Ramello ha scritto:
>> Salve a tutti, mi inserisco perchￜ non riesco proprio a capire come non
>> venga preso in considerazione Postgresql (o Postgres).
>
> qualsiasi database non venga citato, data la genericitￜ della richiesta. :)
In realtￜ mi riferivo in generale. Postgres ￜ un db ignorato e non ne
comprendo francamente il motivo.
Lo uso da anni in applicazioni impegnative e ho avuto solo
soddisfazioni. L'unica cosa ￜ che, con Delphi ho camprato il PgDAC
della Devart cosￜ ci accedo direttamente.
alessandro f
momento...... divertente è vedere che il post "viaggia da solo" verso
altri ambiti non richiesti !!:) cmq.
So cosa sono le transazioni ma non ci ho mai avuto a che fare quindi
al momento ignoro tutte le fasi necessarie per far si che il db si
aggiorni dopo che l'utente ha convalidato un form e renda disponibile
il record anche agli altri utenti che , se ho capito bene , dovranno
cmq rieffettuare la query per vedere il record ? oppure , ad esempio,
alla pressione di un tasto o ogni x secondi l'altro client puo
controllare se il db è stato modificato e rifare da se la query
aggiornando il dbgrid ? (cosi attualmente lavoro)
Si parla di 10000 record x anno e fortunatamente non ho mai avuto
necessità di confronti con gli anni passati. Se l'utente ha necessità
entra nel vecchio archivio che semplicemente di chiama 200x.dat
potrebbe essere un vantaggio ma , anche uno svantaggio nel caso le
dimensioni del DB sono uniche e non archiviabili per anno mettendone a
parte "pezzi alla volta". Avendo un DB unico consente di effettuare
ricerche e confronti su tutti i record ma anche avere un db enorme e
che dovrebbe essere piu lento nelle ricerche immagino? !
normalmente ho 2 o 3 utenti che simultaneamente inseriscono record ma
parliamo di 1 record ogni 5/10 minuti piu varie funzioni di ricerca
sul db per duplicare record etc. Potrei arrivare ad un massimo di 10
client che fanno ricerche e inseriscono sempre 1 o 2 record ogni 5
minuti e quindi "quest'è"
altro parametro per me importante è la longevità. Ovvio che MS SQL non
morirà mai se non per il nome che ha e che varierà nel tempo ...... e
i suoi driver nativi e qui mi viente in mente Firebird e forse anche
Postregre ma ripeto non ho esperienze in merito
Parametro fondamentali sono la longevità+la possibilità di avere
facilmente su 5000 record una estrapolazione degli stessi in una
DBgrid che ad esempio si autoaggiorna sul pc-utente1 se qualcuno da
altra postazione aggiunge un record che rientra nella ricerca fatta
dall'utente pc-utente1. Se pc-utente1 duplica uno dei 5000 record
ritroverà automaticamente il nuovo record nella sua ricerca e puo
entrarci in modifica.
(considerando ovviamente la mia mole di dati e gli accessi simultanei)
Quello che mi preoccupa è che attualmente i moderni SQL hanno una
serie di funzioni che forse a me non servono (tipo gestione controllo
etc) e mi complicherebbero solo la vita nel caso di crash macchina che
danneggia il db o crash applicazione che danneggia sempre il db. Io ho
un "archivio pratiche" con 100 campi e faccio ricerche su 15 di questi
(campi numerici o testo da 35 caratteri max). Ognuna di queste
pratiche puo avere da 1 a 100 sottopratiche collegate alla pratica
madre.
Warp10
> So cosa sono le transazioni ma non ci ho mai avuto a che fare quindi
> al momento ignoro tutte le fasi necessarie per far si che il db si
> aggiorni dopo che l'utente ha convalidato un form e renda disponibile
> il record anche agli altri utenti che , se ho capito bene , dovranno
> cmq rieffettuare la query per vedere il record ? oppure , ad esempio,
> alla pressione di un tasto o ogni x secondi l'altro client puo
> controllare se il db � stato modificato e rifare da se la query
> aggiornando il dbgrid ? (cosi attualmente lavoro)
Io ti parlo di FB.
Come avrai capito non serve un timer perch� � il motore stesso del db
che avvisa i client, tramite gli eventi, che � ora che aggiornino la
visualizzazione. Cosa aggiornare e come farlo �, ovviamente, compito del
programma. FB si limita a dire che bisogna farlo.
Ignoro se altri db abbiano meccanismi simili.
> Si parla di 10000 record x anno e fortunatamente non ho mai avuto
> necessit� di confronti con gli anni passati. Se l'utente ha necessit�
> entra nel vecchio archivio che semplicemente di chiama 200x.dat
> potrebbe essere un vantaggio ma , anche uno svantaggio nel caso le
> dimensioni del DB sono uniche e non archiviabili per anno mettendone a
> parte "pezzi alla volta". Avendo un DB unico consente di effettuare
> ricerche e confronti su tutti i record ma anche avere un db enorme e
> che dovrebbe essere piu lento nelle ricerche immagino? !
Dipende cosa intendi con "enorme".
Io gestisco un db con 200.000 record di materiali e con almeno un paio
di movimenti per materiale. E non � nemmeno uno dei pi� grandi.
Un db client/server serio � fatto apposta per gestire grandi quantit� di
dati. Dove "grandi" pu� anche arrivare, ed a volte arriva senza
problemi, alle sei cifre di record.
Il tuo compito � fare in modo, progettando accuratamente la struttura
del db, che le estrazioni dei dati siano le pi� rapide possibili. Gli
indici servono proprio a questo.
> altro parametro per me importante � la longevit�.
Longevit�... longevit�...
Allora vediamo:
- dBase (dbIII, dbIV e Clipper 1987-1997)
- Access (VB, Delphi 1994-2011 ebbene s�, lo ammetto, ho ancora qualcosa
in Access, ma sto cercando di smettere :) )
- DB2 (2001 un unico progetto)
- Paradox (brevissima parentesi tra Access e Firebird)
- MSSQL (2002 guardato e lasciato subito da parte a favore di Firebird)
- Firebird (2002-2011)
S�, il concetto di db � longevo. :)
Se trovi qualcosa di meglio � ovvio che porti i tuoi dati verso altri
lidi dove possono essere gestiti meglio, altrimenti saremmo ancora tutti
ai file di testo. :)
Enrico 'Henryx' Bianchi
> Sono interessato a postgres: hai qualche link di
> risorse/community/gruppi in italiano ?
Qua trovi la mailing list: http://lists.psql.it/mailman/listinfo/postgresql-
it
Enrico
Enrico 'Henryx' Bianchi
> Qua trovi la mailing list:
:/
http://lists.psql.it/mailman/listinfo/postgresql-it
Enrico
Enrico 'Henryx' Bianchi
> - Un client installato su ogni PC che si connette (non è un "contro" ma
> è una necessità)
Uh? Non dovrebbe bastare fbclient.(dll|so) e amen?
Enrico
Warp10
Sì.
L'ho messo nei "contro" perché, anche se è un solo file, è pur sempre
qualcosa da fornire che sul PC del client non è detto ci sia.
È qualcosa a cui pensare quando si crea l'installazione, insomma.
alessandro f
> Il 13/10/2011 18.11, alessandro f ha scritto:
>
> > So cosa sono le transazioni ma non ci ho mai avuto a che fare quindi
> > al momento ignoro tutte le fasi necessarie per far si che il db si
> > aggiorni dopo che l'utente ha convalidato un form e renda disponibile
> > il record anche agli altri utenti che , se ho capito bene , dovranno
> > cmq rieffettuare la query per vedere il record ? oppure , ad esempio,
> > alla pressione di un tasto o ogni x secondi l'altro client puo
> > controllare se il db stato modificato e rifare da se la query
> > aggiornando il dbgrid ? (cosi attualmente lavoro)
>
> Io ti parlo di FB.
> Come avrai capito non serve un timer perch il motore stesso del db
> che avvisa i client, tramite gli eventi, che ora che aggiornino la
> visualizzazione. Cosa aggiornare e come farlo , ovviamente, compito del
> programma. FB si limita a dire che bisogna farlo.
Quindi anzichè controllare con un timer , devo controllare un evento
usando un timing specifico
> Ignoro se altri db abbiano meccanismi simili.
da profano immagino proprio di si......
ho sentito parlare di FB come ottimo prodotto ma non credo abbia
caratteristiche "cosi' uniche"
a proposito ma è gratuito o a pagamento ?
se acquistassi ANYDAC riuscirei a "svincolarmi" dal DB nel caso un
domani volessi portare i dati su altra piattaforma ? (intesa come DB
non solo come S.O.)
> Il tuo compito fare in modo, progettando accuratamente la struttura
> del db, che le estrazioni dei dati siano le pi rapide possibili. Gli
> indici servono proprio a questo.
Infatti , ipotizzando 10000 record x anno e conservando sempre gli
ultimi 5 addietro , dovrei testare con qualche softwrae quanto tempo
impiegherei a visualizzare in una grid 1500 record selezionati a mezzo
indice
ma la dimensione del DB quindi x le prestazioni non conta ?
io attualmente oltre agli indici faccio delle ricerche sull'intero
record e qui mi sa che "mi faccio male" , dovendoli leggere uno ad uno
a proposito di dbgrid , avete qualche componente terzo da
consigliare ?
> - MSSQL (2002 guardato e lasciato subito da parte a favore di Firebird)
posso chiederti come mai ? che parametri di valutazione hai usato
alessandro f
Infatti
sempre perchè sono completamente allo scuro volevo chiedere :
per utilizzare un DB
bisogna :
1) installare il motore del DB su un server e accerdervi tramite IP
(l'ho visto fare 1 volta con MSSQL)
2) installare il motore in locale nel caso di installazione su singola
postazione ?
3) installare eventuale client oppure DLL come per FB per dialogare
via ANYDAC con il client del DB
giusto ?
Ma il DB come si crea la prima volta ? ci sono tool stesso del DB che
consentono la creazione la prima volta ?
se in futuro c'è bisogno di aggiungere campi al record bisogna
progettare routines ad hoc oppure ci sono funzionalità apposte già nel
motore ?
alessandro f
soddisfacente MSSQL
tra l'altro mi chiedevo, se ho 6 postazioni nel caso di MSSQL EXPRESS
posso cmq utilizzare ma non accedere contemporaneamente in 6 al DB
immagino
ma ......se volessi acquistare una licenza del DB per max 10 utenti
qualcuno puo dirmi quanto potrebbe costare ?
Warp10
> On 13 Ott, 22:43, Warp10<war...@libero.it> wrote:
>> Il 13/10/2011 22.29, Enrico 'Henryx' Bianchi ha scritto:
>>
>>> Warp10 wrote:
>>
>>>> � una necessit�)
>>
>>
>>
>> L'ho messo nei "contro" perch�, anche se � un solo file, � pur sempre
>> qualcosa da fornire che sul PC del client non � detto ci sia.
>>
>> � qualcosa a cui pensare quando si crea l'installazione, insomma.
>
> Infatti
> sempre perch� sono completamente allo scuro volevo chiedere :
>
> per utilizzare un DB
> bisogna :
> 1) installare il motore del DB su un server e accerdervi tramite IP
> (l'ho visto fare 1 volta con MSSQL)
Non accedi al motore, ma al db che � gestito dal motore.
La parte riguardante l'IP � corretta. Quindi � ovvio che l'IP del PC su
cui installi il motore del db deve essere fisso.
> 2) installare il motore in locale nel caso di installazione su singola
> postazione ?
Sul PC che deve connettersi installi la parte client del motore, quella
che colloquia col server. Non devi installare tutto il motore del db.
> Ma il DB come si crea la prima volta ? ci sono tool stesso del DB che
> consentono la creazione la prima volta ?
Io uso FlameRobin che consente una gestione sufficientemente rapida e
semplice, ma non � l'unico attrezzo disponibile.
> se in futuro c'� bisogno di aggiungere campi al record bisogna
> progettare routines ad hoc oppure ci sono funzionalit� apposte gi� nel
> motore ?
Io faccio tutto a livello di codice anche perch� non ho accesso fisico
al server.
In una try...except controllo che il campo che devo creare esista gi�,
se cos� non � lo creo tramite ALTER TABLE...
Se devo creare una tabella nuova controllo, tramite un TIBDatabaseInfo,
che esista un unico utente connesso e se � cos� creo la tabella sempre
tramite SQL, altrimenti esco dal programma e dico all'utente di far
sconnettere gli altri.
La "funzionalit� apposte gi� nel motore" si chiama SQL
(http://en.wikipedia.org/wiki/SQL) che � standard... quasi. :)
Warp10
> Mi piacerebbe sentire anche il parere di qualcuno che usa in maniera
> soddisfacente MSSQL
Ti vengono proposti almeno due db gratuiti (FB e PostgreSQL) e vuoi
usare SQLServer? Auguri. :)
> tra l'altro mi chiedevo, se ho 6 postazioni nel caso di MSSQL EXPRESS
> posso cmq utilizzare ma non accedere contemporaneamente in 6 al DB
> immagino
Da http://en.wikipedia.org/wiki/SQL_Server_Express
- 1 GB of RAM (runs on a system with any RAM amount, but uses only at
most 1 GB)
> ma ......se volessi acquistare una licenza del DB per max 10 utenti
> qualcuno puo dirmi quanto potrebbe costare ?
Qui passo. Le licenze MS sono diventate esame obbligatorio nei master di
enigmistica avanzata. :)
Alberto Salvati
> qualcuno puo dirmi quanto potrebbe costare ?
...un rivenditore...?
Warp10
> Quindi anzich� controllare con un timer , devo controllare un evento
> usando un timing specifico
No.
Il componente TIBEvents ha un metodo OnEventAlert in cui uno dei
parametri � il nome dell'evento ricevuto. A seconda del nome dell'evento
ricevuto dal motore db ti comporti di conseguenza.
Esempio:
- Nel db FB definisci che ad ogni nuovo INSERT nella tabella CLIENTI
parte un evento NEW_CLIENTE
- Al componente di tipo TIBEvents nel data module nel progetto Delphi
arriver� NEW_CLIENTE
- Nell'evento OnEventAlter del componente di tipo TIBEvents scriverai il
codice che deve essere eseguito ad ogni inserimento di un nuovo cliente.
� FB che ti dice che devi fare qualcosa, non sei tu che ogni tot
millisecondi vai a fare dei controlli, magari inutili.
> a proposito ma � gratuito o a pagamento ?
Gratuito e gratuito per davvero.
> Infatti , ipotizzando 10000 record x anno e conservando sempre gli
> ultimi 5 addietro , dovrei testare con qualche softwrae quanto tempo
> impiegherei a visualizzare in una grid 1500 record selezionati a mezzo
> indice
> ma la dimensione del DB quindi x le prestazioni non conta ?
Conta, eccome.
Cos� come conta anche ci� che il tuo cliente ci metter� dentro.
A me � capitato di veder saturare un file FileMaker, non progettato da
me, perch� chi lo usava ci metteva dentro le foto degli oggetti da
inventariare prese direttamente dalla altorisoluzionatissima fotocamera
senza passarle per nessun altro software che le potesse ridurre di
dimensione. Dopo 200 record FileMaker ha alzato bandiera bianca.
Tieni conto, per�, che se non devi gestire Blob, 10.000 record di solo
testo/numeri/date sono poca roba per un db serio come quelli che ti sono
stati consigliati. Persino il buon vecchio dBIII ce la farebbe. :)
> io attualmente oltre agli indici faccio delle ricerche sull'intero
> record e qui mi sa che "mi faccio male" , dovendoli leggere uno ad uno
Non capisco cosa intendi con "ricerche sull'intero record".
Fai fare al cliente un filtro tipo il filtro in base a maschera di Access?
> a proposito di dbgrid , avete qualche componente terzo da
> consigliare ?
Se vuoi restare sul gratis ti consiglio la TJVDBGrid. A pagamento ce ne
sono altre che, per�, non conosco.
>> - MSSQL (2002 guardato e lasciato subito da parte a favore di Firebird)
>
> posso chiederti come mai ? che parametri di valutazione hai usato
Prezzo ed elefantiasi del motore.
giovanni.v
> qualcuno puo dirmi quanto potrebbe costare ?
La versione pi� economica che vedo nel listino ms segna 1.221,95 al
netto di iva.
Effettivamente come gi� fatto notare da Warp10 il licensing MS � un
rebus quindi non vado oltre, prendila come un cut&paste.
Segui i consigli che ti hanno gi� dato su FB/Postgresql che � meglio e
non solo per il prezzo.
--
Design for the future, because it will be here sooner than you think.
(C) Eric S. Raymond, from "The Art of Unix Programming"
Adriana
news:4e96cf24$1...@news.x-privat.org...
>>> L'applicazione rimane in ascolto di questi eventi tramite un componente
>>> (negli IBX c'� TIBevents) e quando arriva l'evento opera le azioni
>>> richieste.
>>
>> Ok ho capito: � proprio quello che voglio fare anche io per il mio
>> programma in qt.
>>
>> http://www.firebirdsql.org/file/documentation/papers_presentations/Power_Firebird_events.pdf
>>
>>
(su Aggiornamento, Inserimento o Cancellazione record) , ma poi qual'e' il
componente (TDataSetPriver o TClientDataSet) che si fa carico di
intercettare l'evento ?
usando TSQLConnection, TClientDataSet, TDataSetProvider, TSqlStoredProcedure
e TDaSource, e sempre con ApplyUpdates(-1), fino a che non faccio un
refresh, non mi accorgo se un record e' stato variato e eliminato.
Uso Delphi XE, il componente TIBEvent credo usasse un timer per verificare
le variazioni del db.
Alberto Salvati
Warp10
> Uso Delphi XE, il componente TIBEvent credo usasse un timer per verificare
> le variazioni del db.
TIBEvents e scrivi del codice per gestire l'evento nell'OnEventAlert
Esempio:
if (eventname = 'new_prenotazione') or (eventname = 'del_prenotazione') then
begin
main.tbaggiornaClick(sender);
end;
Warp10
> Quanta gente nuova che scrive in questo post.....
Se ti riferisci a me ho perso l'attributo di "nuovo" da... oh... da
prima che tu nascessi. :)
Enrico 'Henryx' Bianchi
> Mi piacerebbe sentire anche il parere di qualcuno che usa in maniera
> soddisfacente MSSQL
Diciamo che lo uso per lavoro assieme ad altri motori di database (Oracle in
primis) :)
> tra l'altro mi chiedevo, se ho 6 postazioni nel caso di MSSQL EXPRESS
MSDE, ovvero di una versione decisamente vecchia di SQL Server Express.
Attualmente i limiti di SQL Express 2008 R2 sono altri, ma non a livello di
connessioni contemporanee
> ma ......se volessi acquistare una licenza del DB per max 10 utenti
> qualcuno puo dirmi quanto potrebbe costare ?
Firebird o PostgreSQL (preferendo il primo) in modo da non avere alcun
limite imposto se non quello architetturale della scelta da te fatta (e`
ovvio che ogni RDBMS ha le sue caratteristiche che lo fanno preferire ad un
altro RDBMS)
Enrico
Enrico 'Henryx' Bianchi
> ma la dimensione del DB quindi x le prestazioni non conta ?
lenta nel restituire i dati rispetto ad una che ne contiene 1k, soprattutto
se non vi sono indicizzazioni per la query eseguita
Enrico
Enrico 'Henryx' Bianchi
> stavo pensando di separare il DB uno per ogni
> anno per semplificare la gestione dei dati vecchi
Se devi fare per forza una porcata del genere, allora tanto vale che esegui
un partizionamento logico dei dati su database (ovvero crei una tabella per
anno) e poi li unisci tramite una vista (non ricordo pero` se Firebird
gestisce trigger su vista)
Enrico
morde
> io attualmente oltre agli indici faccio delle ricerche sull'intero
> record e qui mi sa che "mi faccio male" , dovendoli leggere uno ad uno
Alberto Salvati
> un partizionamento logico dei dati su database
usarlo se la tabella ha VERAMENTE tanti record....
Data la mole di dati, io accantonerei tutte ste questioni.
Con 10000 record anche SqlServer potrebbe andare... :-D
A.
alessandro f
pongo altri miei dubbi....
1) Alter table per inserire un campo in un db gestito via software dal
client. ok.
Mando il comando e il motore DB ricostruisce il db (con i tempi
debiti) e allo stesso tempo lockko il DB per evitare che altri utenti
vi accendano ? (c'è possibilità di interno lock di un db su FB e
POSTgre? )
2) avevo chiesto pareri sul licensing di MSSQL proprio xke "li
conosco" ....immaginavo il dedalo da districare quindi un parere x chi
aveva già percorso il labirinto ...
In ogni caso mi piacerebbe avere una panoramica completa anche dei DB
non a pagamento.
Un motivo del perchè qualcuno li paga ci sarà?? (a parte il "pushing
politico/requisiti tecnici di winXX".. di microsoft)
magari scopro qualche funzionalità che potrebbe ritornare utile. Non
sono cosi avverso ad acquistare i software di terzi anche i DB (quando
sono accettabili ma sopratutto ne vale la pena o mi servono)
3) Non gestiro' campi blob ma solo date numeri e anche molto testo....
righe da 75 caratteri l'una (per 15 campi e anche piu)
4) pensavo alla "porcata" del dividere il DB proprio per questa
faccenda delle ricerche. Siccome a me sostanzialmente non occorre fare
molti confronti col passato ma invece occorre visualizzare in una GRID
tutti i record che magari in uno dei tanti campi da 75 caratteri c'è
scritto la dicitura "PORCATA" allora gestire questa ricerca su XX anni
con un DB morderno...mi sa che posso lasciare il pc e andare giu al
bar prima di vedere il risultato.
Se ho capito bene si progettano gli indici dall'inizio (questo si fà
all'atto della creazione del DB o anche dopo? magari con quel
FLAMEROBIN citato ?
come faccio ad indicizzare 15 campi che sono da 75 caratteri l'uno ??
mi viene un file indice che non finisce più. e già la ricerca su uno
di questi campi da effettuare su 5000record anno mi sa che ......... i
caffè devono diventare almeno 2 o 3 :) .... ovvio che ipotizzo xke non
ho esperienze in merito
immagino pero' che se devo fare questo tipo di ricercha dovro'
leggermi i record uno ad uno x evitare di avere degli indici
stratosferici su ogni campo da 75car.
Allora a questo punto potrei anche ipotizzare che con l'indice per
anno quantomeno leggo tutti i record uno ad uno ......solo quelli
dell'anno X e quindi forse .... potrei anche pensare di tenere un
unico DB
altro pensiero che facevo è.....se qualcuno come l'antivirus ,,,,il
server che si inceppa ......l'utente che rompe le@@ ..mi sputtana il
DB .....lo farà su tutti gli anni e perde tutto ???
5) richiesta di ulteriore consiglio : attualmente ho un DB fatture, DB
pratiche, DB bolle , DB xxxx, DB yyyyy
che sono collegati tutti da un numero di pratica e hanno ovviamente
dei campii in comune oltre che
in ogni DB ci sono delle tabelle "fisse" (come clienti tariffe etc )
che sono anche in comune ai vari DB
Potrei ipotizzare di mettere tutto in un unico DB ?
la questione è che alcuni utenti usano 4 applicazioni e 4 DB altri
solo alcune. In questo caso non si pone il problema xke alcuni
userebbero tutti i db e altri no che resterebbero vuoti..
Oltrepassate le riflessioni sui costi delle licenze dovrei considerare
la questione delle prestazioni e delle funzionalità specifiche.
Immagino che non è disponibile online qualche documento di qualcuno
che parli di performances
Ora ritorno sullo stesso punto, è il caso di separare i DB principali
anzichè mettere tutti in unico calderone
(sempre per la questione della velocità) ?
Se mettessi tutto nello stesso calderone avrei la sommatoria dei vari
indici cioè indice cliente per le fatture indice cliente per le
pratiche etc etc
Se separo i DB "cosa ci vuole per andare" ad aprire il DB pratiche ,
prendere una pratica associargli il numero di fattura, aggiornare la
pratica e , un domani dal DB fatture pescare il numero di pratica e
andare ad aprire il DB pratiche con tale numero e cosi "complicato" da
dover scegleire anche qui un DB unico per tutto ?
6) Ultimo quesito e chiudo
Qualcuno conosce forum/siti/documenti dove vengono comparate le
specifiche pecurialità di FB e Postgre ?
almeno potrei farmi una idea se le singole funzioni X o Y mi servono e
quindi poi scegliere... sono cmq orientato su uno dei 2. Ho letto che
FB è il DB piu "vecchio ed utilizzato" da Delphi mentre Postgre è un
DB di data più vecchia ed utilizzato da un numero maggiore di utenti
su varie piattaforme
Mi è stato anche detto che i DB relazionali non si sposano bene con lo
scorrimento in una grid anche se non ne capisco il motivo.
p.s. FB+applicazione delphi puo essere installato su un sistema
Apple ? mi pare PostGre si
morde
> p.s. FB+applicazione delphi puo essere installato su un sistema
> Apple ? mi pare PostGre si
operativo dei clienti, allora non c'č scampo: devi usare una macchina
virtuale. Che io sappia, delphi su MAC non gira nativo.
alessandro f
> On 17.10.2011 17:40, alessandro f wrote:
>
> > p.s. FB+applicazione delphi puo essere installato su un sistema
> > Apple ? mi pare PostGre si
>
> operativo dei clienti, allora non c' scampo: devi usare una macchina
>
principali .......e cmq il nuovo XE è cross platform .........o almeno
dovrebbe
Enrico 'Henryx' Bianchi
> Oracle ha il partizionamento logico ma nei loro documenti invitano a
> usarlo se la tabella ha VERAMENTE tanti record....
di una tabella partizionata suddivide i dati in slice opportunamente
configurate. Per partizionamento logico intendo la creazione di n tabelle
identiche unite con una vista a cui viene agganciato un trigger che
redireziona i dati secondo i criteri scelti (e.g. anno di inserimento)
Enrico
P.S. da questo punto di vista PostgreSQL permette una migliore gestione dei
partizionamenti logici, ma ancora non implementa quelli fisici
Enrico 'Henryx' Bianchi
> Un motivo del perchè qualcuno li paga ci sarà??
sviluppato in cui i dati potevano stare benissimo su Firebird (scartato
all'epoca a causa di problemi con i driver JDBC) o su PostgreSQL, fu scelto
Oracle perche` "qui usiamo solo Oracle"
Enrico
morde
> fu scelto
> Oracle perche` "qui usiamo solo Oracle"
database". Tipico..
Alberto Salvati
> 1) Alter table per inserire un campo in un db gestito via software dal
> client. ok.
> Mando il comando e il motore DB ricostruisce il db (con i tempi
> debiti) e allo stesso tempo lockko il DB per evitare che altri utenti
> vi accendano ? (c'è possibilità di interno lock di un db su FB e
> POSTgre? )
Se il campo ha un constraint (not null e/o foreign key) e hai gia'
dei record nella tabella va tutto ai festini del nano di Arcore.
La modifica STRUTTURALE di un db relazionale va PENSATA, GESTITA E
FATTA SOLO SE SERVE DAVVERO.
> Un motivo del perchè qualcuno li paga ci sarà?? (a parte il "pushing
> politico/requisiti tecnici di winXX".. di microsoft)
1) C'e' gente che non CONCEPISCE NIENTE CHE NON ABBIA IL LOGO DI ZIO
BILLY.
Quindi, winzozz, sqlserver, visual studio, asp.net....
2) C'e' gente che usa Oracle xche "oracle e' potente".....
3) C'e' gente che usa Java xche "e' multipiattaforma"
>
> 4) pensavo alla "porcata" del dividere il DB proprio per questa
> faccenda delle ricerche. Siccome a me sostanzialmente non occorre fare
> molti confronti col passato ma invece occorre visualizzare in una GRID
> tutti i record che magari in uno dei tanti campi da 75 caratteri c'è
> scritto la dicitura "PORCATA" allora gestire questa ricerca su XX anni
> con un DB morderno...mi sa che posso lasciare il pc e andare giu al
> bar prima di vedere il risultato.
Se si, mi spieghi che prove hai fatto e cosa hai usato?
Giusto per...
Ho una tabella che al momento ha 58 campi.
Questa tabella CRESCE. Nel db che uso per i test al momento ho circa
600.000 record.
Db oracle 10g col server che gira sul mio stesso pc (xp sp3).
Sullo stesso pc ho delphi, un software di una terza parte scritto
in .net, un fottio di software installato, firebird server e 8 diversi
software per vpn varie.
> Se ho capito bene si progettano gli indici dall'inizio (questo si fà
> all'atto della creazione del DB o anche dopo? magari con quel
> FLAMEROBIN citato ?
restando le ovvie (ma non x tutti..) eccezioni dettate la buon senso.
Il motore db in genere, se li trova li usa altrimenti ne fa a meno.
> come faccio ad indicizzare 15 campi che sono da 75 caratteri l'uno ??
> mi viene un file indice che non finisce più. e già la ricerca su uno
> di questi campi da effettuare su 5000record anno mi sa che ......... i
> caffè devono diventare almeno 2 o 3 :) .... ovvio che ipotizzo xke non
> ho esperienze in merito
IPOTIZZI.
Installa un firebird, creati una tabella, buttaci dentro i dati e
PROVA.
Ancor prima di questo, c'e' la ovvia (ma non per tutti) domanda
preliminare:
IL DB E' PROGETTATO COME SI DEVE OPPURE HA UNA STRUTTURA CINOFALLICA?
Quanti sono i possibili valori per i 15 campi di 75 caratteri?
> immagino pero' che se devo fare questo tipo di ricercha dovro'
> leggermi i record uno ad uno x evitare di avere degli indici
> stratosferici su ogni campo da 75car.
Scrivi select * from qualchetabella where qualchecmapo=qualevalore
Non sei TU as scorrere: ci pensa il motore db.
> altro pensiero che facevo è.....se qualcuno come l'antivirus ,,,,il
> server che si inceppa ......l'utente che rompe le@@ ..mi sputtana il
> DB .....lo farà su tutti gli anni e perde tutto ???
Per il resto, a anche a rischio di scatenare un flame, sono convinto
che un motore db client/server sia piu' pensato per la sicurezza che
per la velocita'.
Che poi siano foto porno, video porno, documenti legali o illegali,
codice sorgente, fogli di calcolo, etc...L'UTENTE DEVE FARE I BACKUP.
A parte tutto, la difficolta' maggiore e' all'inizio. Si chiama
PREPARAZIONE.
Tu stai partendo in quarta a fare un qualcosa usando strumenti che non
conosci e senza le necessarie basi teoriche.
A differenze del teatro e della cucina, nel campo del software
l'improvvisazione NON VA BENE.
A.
alessandro f
partizionamento logico "per anno"
credi tra l'altro che le prestazioni sulle ricerche aumentino
separando gli anni in diverse tabelle ?
mi viene un dubbio, si puo creare una nuova tabella da una
preesistente e distinguerla per anno ?
x Alberto
- la preghiera delle copie quotidiane la pratico anch'io da anni
ma ... nessuno a parte aziende di "grosse dimensioni" spendono risorse
nel addestrare qualcuno ALMENO per controllare quotidianamente che
vengano fatte e ....puntualmente..quando serve la copia ...ci si
accorge che l'ultima è di 1 mese fà .....se tutto va bene ....quindi a
mio modesto parere le copie non sono una soluzione ad un DB
inaffidabile e che perde i dati
- non parto in quarta ne "improvviso" , sto solo confrontandomi con
qualcuno che ne sa piu di me e mi puo dirigere con qualche consiglio
verso un DB da installare e testare cosi come giustamente suggerisci e
senza dover fare questa operazione 1 ad uno per almeno 4 5 o 6 DB di
maggiore diffusione partendo dal fatto che dovrei approfondire le basi
teoriche di tutti e 6. Quindi il tuo consiglio lo accetto volentieri.
Devo fare un corso di progettazione DB .......se lo trovo.
Tra l'altro mi risulterebbe difficile senza nemmeno avere una
applicazione a mettere dentro un FB 10000 record "cosi' al volo" ...
devo studiarmi il DB come realizzarlo, scrivere un programmino delphi,
come progettarlo ETC e con i vs consigli sto prendendo idee e vi
ringrazio
- i possibili valori dei campi stringa da 75 caratteri sono INFINITI
visto che si tratta di testo libero e non di campi da compilare a
mezzo tabelle preconfigurate.
- mi capita almeno un paio di volte all'anno di "aggiungere un campo"
visto che non sono io a decidere a priori le necessità dei miei utenti
e nemmeno loro, neanche se avessi una sfera di cristallo purtroppo.
Negli ultimi anni ci ho provato, inserendo dei campi "in previsione" e
a volte mi è andata bene a volte no.
E' cosi problematico aggiungere un campo in una tabella in un DB?
(considerando che fortunatamente ho la possibilità di avere dei fermo
macchina visto che le mie applicazioni non sono usate (purtroppo) da
banche/telecom/etc) ?
Stessa domanda.
Se ho 1 db per le fatture e 1 db per le pratiche quali sono le
controindicazioni nell'avere 2 db separati e leggere i record nei 2 DB
x scambiare parzialmente alcuni dati ?
Qui per rispondere a questa domanda non basta installare ma
bisognerebbe sviluppare tutto e poi capire ....quindi chiedo a chi
magari si è già trovato in una condizione simile per avere spunti e
suggerimenti (anche a questo servono i forum .no ?)
La soluzione dell'unico calderone mi fa un po paura. Avevo ipotizzato
di avere un unico DB con le tabelle relative ai campi in comune come
elenco clienti , elecno codici iva (faccio x esempio) , e che sono in
comune a tutte le applicazioni.
Separare invece il DB fatture da quello delle pratiche.
C'è qualcuno che ha un esempio pratico di una necessità che lo ha
spinto ad avere un unico DB per fatture e pratiche ? (parlo di fatture
e pratiche solo x esempio)
- Mi verrebbe da chiederti di fare un test sul tuo DB da 600.000
record da 58 campi (di cui 15 sono testo a 75 caratteri)
"Scrivi select * from qualchetabella where qualchecmapo=qualevalore -
Warp10
> Allora...... rispondo in un unico post alle varie questioni......e
> pongo altri miei dubbi....
>
> 1) Alter table per inserire un campo in un db gestito via software dal
> client. ok.
> Mando il comando e il motore DB ricostruisce il db (con i tempi
> debiti) e allo stesso tempo lockko il DB per evitare che altri utenti
> vi accendano ? (c'è possibilità di interno lock di un db su FB e
> POSTgre? )
N client connessi (fatto N-mila volte in maniera trasparente
all'utente). La creazione di una nuova tabella, con eventuale nuovo
generatore, no. Un unico client e stop. Se ce n'è più di uno la tabella
non viene creata. Verrà creata nel momento in cui c'è un unico client
connesso.
> Un motivo del perchè qualcuno li paga ci sarà?? (a parte il "pushing
> politico/requisiti tecnici di winXX".. di microsoft)
> 3) Non gestiro' campi blob ma solo date numeri e anche molto testo....
> righe da 75 caratteri l'una (per 15 campi e anche piu)
> 4) pensavo alla "porcata" del dividere il DB proprio per questa
> faccenda delle ricerche. Siccome a me sostanzialmente non occorre fare
> molti confronti col passato ma invece occorre visualizzare in una GRID
> tutti i record che magari in uno dei tanti campi da 75 caratteri c'è
> scritto la dicitura "PORCATA" allora gestire questa ricerca su XX anni
> con un DB morderno...mi sa che posso lasciare il pc e andare giu al
> bar prima di vedere il risultato.
connessi, dalla struttura del db, dagli indici, dalla velocità della
rete, dalla velocità dei client...
> Se ho capito bene si progettano gli indici dall'inizio (questo si fà
> all'atto della creazione del DB o anche dopo? magari con quel
> FLAMEROBIN citato ?
nuovi campi.
> come faccio ad indicizzare 15 campi che sono da 75 caratteri l'uno ??
> mi viene un file indice che non finisce più. e già la ricerca su uno
> di questi campi da effettuare su 5000record anno mi sa che ......... i
> caffè devono diventare almeno 2 o 3 :) .... ovvio che ipotizzo xke non
> ho esperienze in merito
> immagino pero' che se devo fare questo tipo di ricercha dovro'
> leggermi i record uno ad uno x evitare di avere degli indici
> stratosferici su ogni campo da 75car.
Per questa tua applicazione, ora, cosa usi come db?
> altro pensiero che facevo è.....se qualcuno come l'antivirus ,,,,il
> server che si inceppa ......l'utente che rompe le@@ ..mi sputtana il
> DB .....lo farà su tutti gli anni e perde tutto ???
sono quelli Access perché si possono aprire facilmente.
Un db FireBird è gestibile solo tramite un programma come FlameRobin o
altro che puoi installare solo sul server in una locazione nascosta
all'utente normale.
> 5) richiesta di ulteriore consiglio : attualmente ho un DB fatture, DB
> pratiche, DB bolle , DB xxxx, DB yyyyy
> che sono collegati tutti da un numero di pratica e hanno ovviamente
> dei campii in comune oltre che
> in ogni DB ci sono delle tabelle "fisse" (come clienti tariffe etc )
> che sono anche in comune ai vari DB
> Potrei ipotizzare di mettere tutto in un unico DB ?
DB GESTIONE
Tabella fatture
Tabella pratiche
Tabella bolle
...
> la questione è che alcuni utenti usano 4 applicazioni e 4 DB altri
> solo alcune. In questo caso non si pone il problema xke alcuni
> userebbero tutti i db e altri no che resterebbero vuoti..
Un'applicazione che chiede all'utente "Chi sei?".
L'utente ha dei privilegi, impostati da un altro utente (superutente), e
può o non può fare determinate cose (leggi, scrivi, elimina) sulle varie
tabelle raggruppate in un unico db.
> Mi è stato anche detto che i DB relazionali non si sposano bene con lo
> scorrimento in una grid anche se non ne capisco il motivo.
Alberto Salvati
> - mi capita almeno un paio di volte all'anno di "aggiungere un campo"
> visto che non sono io a decidere a priori le necessità dei miei utenti
> e nemmeno loro, neanche se avessi una sfera di cristallo purtroppo.
> Negli ultimi anni ci ho provato, inserendo dei campi "in previsione" e
> a volte mi è andata bene a volte no.
> E' cosi problematico aggiungere un campo in una tabella in un DB?
> (considerando che fortunatamente ho la possibilità di avere dei fermo
> macchina visto che le mie applicazioni non sono usate (purtroppo) da
> banche/telecom/etc) ?
la tua app in condizioni di gestirlo...
> Se ho 1 db per le fatture e 1 db per le pratiche quali sono le
> controindicazioni nell'avere 2 db separati e leggere i record nei 2 DB
> x scambiare parzialmente alcuni dati ?
0) DEVI CHIARIRTI BENE LE IDEE TRA IL CONCETTO DI "DB" E QUELLO DI
"TABELLA".
Quella delle fatture, dei clienti, dei fornitori, dei codici iva,
delle plusvalenze iva sono TABELLE.
Un db clientr/server e' grosso modo un insieme di tabelle, trigger,
indici, stored procedure.
1) FARE QUERY SU PIU' DB DIVERSI NON E' UNA COSA CHE TUTTI I DB FANNO.
E CHI LO FA SPESSO TI COSTRINGE A FARE DEL LAVORO IN PIU'.
2) AVERE PIU' DB NON TI SERVE AD UN KAZEN
Ovviamente, ma non per tutti, se fai girare il motore db su un 286 il
tutto sara' ovviamente lento.
3) L'UNICO MODO CHE HAI PER RENDERTI CONTO DI PERSONA DELLE
PERFORMANCE E' CREARE UN DB CON UNA TABELLA SIMILE A QUELLA PIU'
GROSSA CHE GESTISCI ADESSO E SU DI ESSA CREI DEGLI INDICI SUI CAMPI
CHE TI SERVONO PER LA RICERCA. POI GLI BUTTI DENTRO CON UNA APP
SCRITTA AL VOLTO 600.000 RECORD E POI PROVI A FARE DELLE QUERY. Ti
segni i tempi. Poi, riavvii la macchina e rifai le prove.
A.
Enrico 'Henryx' Bianchi
> Un motivo del perchè qualcuno li paga ci sarà?? (a parte il "pushing
> politico/requisiti tecnici di winXX".. di microsoft)
oltre al prodotto, di solito hai anche un supporto tecnico fornito
direttamente dalla casa madre, cosa che per un'azienda si rivela molto
importante
Enrico
Alberto Salvati
> oltre al prodotto, di solito hai anche un supporto tecnico fornito
> direttamente dalla casa madre, cosa che per un'azienda si rivela molto
> importante
pervasive.
Ho cambiato molte aziende ma non ho mai sentito di contatti con i
relativi produttori per avere supporto.
A.
alessandro f
pensare .......con microsoft......
o si ha un supporto che fa pena .....ho ti costa un botto
invece se ho capito bene con FB e/o Postgre bisogna affidarsi ai forum
e alla bontà altrui
Marco Breveglieri
> Uso db commerciali dal 2000: Sybase, SqlServer, Oracle, db2,
> pervasive.
> Ho cambiato molte aziende ma non ho mai sentito di contatti con i
> relativi produttori per avere supporto.
In altri casi, il solo fatto di avere comunque un supporto tecnico, anche se non viene utilizzato, può essere una obbligatorietà dettata da clausole particolari nei contratti di fornitura del software per cui è obbligatorio individuare un produttore che dia questo tipo di servizio, indipendentemente dal fatto che venga poi sfruttato oppure no.
Ciao,
Marco.
--
MARCO BREVEGLIERI
#Home: http://www.marco.breveglieri.name
#Blog: http://www.compilaquindiva.net
alessandro f
> N client connessi (fatto N-mila volte in maniera trasparente
> all'utente). La creazione di una nuova tabella, con eventuale nuovo
> generatore, no. Un unico client e stop. Se ce n'è più di uno la tabella
> non viene creata. Verrà creata nel momento in cui c'è un unico client
> connesso.
viene assegnato ad ogni nuovo record ?
> > 3) Non gestiro' campi blob ma solo date numeri e anche molto testo....
> > righe da 75 caratteri l'una (per 15 campi e anche piu)
>
> Non ci vedo grandi problemi, anzi, non ce ne vedo proprio.
> > 4) pensavo alla "porcata" del dividere il DB proprio per questa
> > faccenda delle ricerche. Siccome a me sostanzialmente non occorre fare
> > molti confronti col passato ma invece occorre visualizzare in una GRID
> > tutti i record che magari in uno dei tanti campi da 75 caratteri c'è
> > scritto la dicitura "PORCATA" allora gestire questa ricerca su XX anni
> > con un DB morderno...mi sa che posso lasciare il pc e andare giu al
> > bar prima di vedere il risultato.
>
> Dipende. Dipende dalla velocità del server, dal numero di client
> connessi, dalla struttura del db, dagli indici, dalla velocità della
> rete, dalla velocità dei client...
un DB ha 10 tabelle , indipendentemente dal resto e dal numero di
indici , sarà più lento di un DB che ne ha 5 .........allora mi regolo
di conseguenza
> > Se ho capito bene si progettano gli indici dall'inizio (questo si fà
> > all'atto della creazione del DB o anche dopo? magari con quel
> > FLAMEROBIN citato ?
>
> Sì, ma nulla ti vieta di aggiungerne quando e se ti servono a causa di
> nuovi campi.
mouse" i campi nella tabella
Se volessi creare un DB da delphi direttamente andando a scrivere a
mano l'elenco dei campi ?
c'è questa possibilità ?
visto che sono molto abile e veloce con copy/paste avevo intenzione di
ricopiare le mie attuali tabelle con nomi e specifiche da un vecchio
programma turbo pascal ...... magari era + veloce il passaggio e poi
con flame robin andrei a creare gli indici
>
> > come faccio ad indicizzare 15 campi che sono da 75 caratteri l'uno ??
>
> CREATE INDEX <nome> ON <tabella> (<colonna1>, <colonna2,...)
>
> > mi viene un file indice che non finisce più. e già la ricerca su uno
> > di questi campi da effettuare su 5000record anno mi sa che ......... i
> > caffè devono diventare almeno 2 o 3 :) .... ovvio che ipotizzo xke non
> > ho esperienze in merito
> > immagino pero' che se devo fare questo tipo di ricercha dovro'
> > leggermi i record uno ad uno x evitare di avere degli indici
> > stratosferici su ogni campo da 75car.
>
> Dopo tante domande tue te ne posso fare una io?
100 campi dovrei creare 100 indici .... my god
> Per questa tua applicazione, ora, cosa usi come db?
rappresenta 1 solo indice principale , il resto viene fatto leggendo i
record uno ad uno , ovviamente cio comporta lentezza quando si arriva
a 10000 rk però nonostante tutto visto che non faccio uso della
programmazione windows con DB etc , è VELOCE anche in rete con gli
utenti e tutto il resto (e senza server stratosferici ne 100 indici)
> > altro pensiero che facevo è.....se qualcuno come l'antivirus ,,,,il
> > server che si inceppa ......l'utente che rompe le@@ ..mi sputtana il
> > DB .....lo farà su tutti gli anni e perde tutto ???
>
> Ti è già stato detto e sottoscrivo. Gli unici db che ho visto sputtanati
> sono quelli Access perché si possono aprire facilmente.
> Un db FireBird è gestibile solo tramite un programma come FlameRobin o
> altro che puoi installare solo sul server in una locazione nascosta
> all'utente normale.
maggiori automatismi
> Quelli che tu chiami DB diventano le tabelle dell'unico DB.
>
> DB GESTIONE
> Tabella fatture
> Tabella pratiche
> Tabella bolle
> ...
>
> > la questione è che alcuni utenti usano 4 applicazioni e 4 DB altri
> > solo alcune. In questo caso non si pone il problema xke alcuni
> > userebbero tutti i db e altri no che resterebbero vuoti..
>
> Accidenti, tu sì che sai come complicarti l'esistenza! :)
ancora non capisco il motivo nel voler scegliere 1 unico DB anziche 4
e proporre 1 DB con 4 tabelle
>
> Un'applicazione che chiede all'utente "Chi sei?".
> L'utente ha dei privilegi, impostati da un altro utente (superutente), e
> può o non può fare determinate cose (leggi, scrivi, elimina) sulle varie
> tabelle raggruppate in un unico db.
> > Mi è stato anche detto che i DB relazionali non si sposano bene con lo
> > scorrimento in una grid anche se non ne capisco il motivo.
>
> Uso un termine tecnico: balle.
ACSH
microsoft/software commerciale VS. supporto software open source" (ma
stiamo
andando OT)?
ACSH
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ab...@newsland.it
morde
> Ho visto Flamerobin e vedo che da la possiblità di creare "a mano col
> mouse" i campi nella tabella
> Se volessi creare un DB da delphi direttamente andando a scrivere a
> mano l'elenco dei campi ?
tool dedicati a quello specifico scopo, come flamerobin ad esempio.
Documentati anche qui:
http://groups.google.com/group/it.comp.lang.delphi/msg/74fd281ea40d069c
> c'è questa possibilità ?
> visto che sono molto abile e veloce con copy/paste avevo intenzione di
> ricopiare le mie attuali tabelle con nomi e specifiche da un vecchio
> programma turbo pascal ...... magari era + veloce il passaggio e poi
> con flame robin andrei a creare gli indici
vecchio database e ricostruirti tutto da capo usando i dati nativi di
firebird.
Mi spiego meglio: se nel vecchio codice hai un campo di 10 char, in
firebird userai un VARCHAR, che viene gestito meglio e ottimizza lo
spazio. Prendilo con le molle come consiglio, perchè è ovvio che i campi
devono essere compatibili con il codice che li leggeva dal vecchio db,
sennò tanto vale riscriversi tutto da capo.
morde
> Uso db commerciali dal 2000: Sybase, SqlServer, Oracle, db2,
> pervasive.
> Ho cambiato molte aziende ma non ho mai sentito di contatti con i
> relativi produttori per avere supporto.
ho lavorato nella produzione di software per la logistica e ad un certo
punto avemmo un problema sul database (DB2 v7) molto serio.
Dovemmo chiamare IBM e farci mandare un suo super-esperto di DB2 che,
pagato profumatamente, fece veramente il suo lavoro di superesperto e ci
analizzò tutto, dalla a alla z, di quel database, aiutandoci a uscirne
fuori.
morde
> Be questa mi sembra una risposta molto sensata anche se mi viene da
> pensare .......con microsoft......
> o si ha un supporto che fa pena .....ho ti costa un botto
> invece se ho capito bene con FB e/o Postgre bisogna affidarsi ai forum
> e alla bontà altrui
ottieni dipende dalle domande che poni.
Nei progetti OS normalmente uno le cose se non le capisce le deve prima
studiare, approfondire, poi le può chiedere. Il concetto di RTFM è
sempre in vigore. Questo perchè nei progetti opensource la gente non
perde il poco tempo che da volontariamente al progetto per rispondere
alle domande già contemplate nelle FAQ o nella KB del progetto (o nel
codice, nei casi più estremi...).
Se invece paghi un servizio di assistenza, allora aspettati che per 100
euro loro ti rispondano a tutte le domande (anche banali) che tu possa
fare nel tempo acquistato.
Una cosa certa è che le risposte che ottieni dal team firebird
sicuramente sono di qualità, non è altrettanto scontato nel caso di
supporti commerciali.
Per chiudere il discorso: tieni sempre presente questo concetto che
dietro l'open source ci deve essere sempre una componente di
autoformazione, quel "darsi da fare" che ti porta a crescere e a
investire su di te. Se tu decidi di passare a firebird, stai investendo
su di te e sulle tue capacità di impararlo e gestirlo.
Warp10
>> Ti posso dire che l'ALTER TABLE per aggiungere un campo si può fare con
>> N client connessi (fatto N-mila volte in maniera trasparente
>> all'utente). La creazione di una nuova tabella, con eventuale nuovo
>> generatore, no. Un unico client e stop. Se ce n'è più di uno la tabella
>> non viene creata. Verrà creata nel momento in cui c'è un unico client
>> connesso.
>
> Bene, credo possa bastare. Nuovo generatore intendi l'ID univoco che
> viene assegnato ad ogni nuovo record ?
creare campi autoincrementanti. Nel TIBDataSet degli IBX è presente una
proprietà GeneratorField col quale colleghi generator, campo da gestire
della tabella, incremento (quasi sempre 1) e tempo dell'evento (On New
Record (default), On Post, On Server).
Alla creazione di ogni nuovo record il campo della tabella collegata al
generator viene automaticamente incrementato da FB. Semplice, pulito,
veloce e sicuro.
>>> 4) pensavo alla "porcata" del dividere il DB proprio per questa
>>> faccenda delle ricerche. Siccome a me sostanzialmente non occorre fare
>>> molti confronti col passato ma invece occorre visualizzare in una GRID
>>> tutti i record che magari in uno dei tanti campi da 75 caratteri c'è
>>> scritto la dicitura "PORCATA" allora gestire questa ricerca su XX anni
>>> con un DB morderno...mi sa che posso lasciare il pc e andare giu al
>>> bar prima di vedere il risultato.
>>
>> Dipende. Dipende dalla velocità del server, dal numero di client
>> connessi, dalla struttura del db, dagli indici, dalla velocità della
>> rete, dalla velocità dei client...
>
> E lo so.... se però posso "progettare" con informazioni del tipo : se
> un DB ha 10 tabelle , indipendentemente dal resto e dal numero di
> indici , sarà più lento di un DB che ne ha 5 .........allora mi regolo
> di conseguenza
prestazioni di un DB.
>>> Se ho capito bene si progettano gli indici dall'inizio (questo si fà
>>> all'atto della creazione del DB o anche dopo? magari con quel
>>> FLAMEROBIN citato ?
>>
>> Sì, ma nulla ti vieta di aggiungerne quando e se ti servono a causa di
>> nuovi campi.
>
> Ho visto Flamerobin e vedo che da la possiblità di creare "a mano col
> mouse" i campi nella tabella
> Se volessi creare un DB da delphi direttamente andando a scrivere a
> mano l'elenco dei campi ?
per creare campi o tabelle.
>> Per questa tua applicazione, ora, cosa usi come db?
>
> un file di testo che rappresenta il db + un file di testo che
> rappresenta 1 solo indice principale , il resto viene fatto leggendo i
> record uno ad uno , ovviamente cio comporta lentezza quando si arriva
> a 10000 rk però nonostante tutto visto che non faccio uso della
> programmazione windows con DB etc , è VELOCE anche in rete con gli
> utenti e tutto il resto (e senza server stratosferici ne 100 indici)
cosa che *è* un DB si comporti alla stessa maniera.
FB (o qualunque altro motore di db client/server) è stato creato apposta
per gestire una grande mole di dati (con "grande" molto maggiore di
10.000 record). Ovviamente deve essere aiutato da te con la creazione
dei giusti indici per poterlo fare, ma una volta messa a punto la
struttura generale del DB le prestazioni sono molto ma molto buone.
Oltre a questo un db client/server ti offre degli automatismi, primo fra
tutti le foreign key, che servono per salvaguardare la coerenza dei dati.
>> Accidenti, tu sì che sai come complicarti l'esistenza! :)
>
> ehehe no sto cercando la soluzione migliore
> ancora non capisco il motivo nel voler scegliere 1 unico DB anziche 4
> e proporre 1 DB con 4 tabelle
la discussione. :)
Ti dico che, di solito, si aggregano in un unico DB le tabelle che
riguardano l'argomento di uno specifico programma.
Io ho sei software attivi che usano sei DB diversi perché ogni software
tratta un argomento specifico (inventario, vestiario, magazzino,
automezzi...). Tutti i DB condividono le informazioni sugli uffici, ad
esempio.
>>> Mi è stato anche detto che i DB relazionali non si sposano bene con lo
>>> scorrimento in una grid anche se non ne capisco il motivo.
>>
>> Uso un termine tecnico: balle.
>
> heehe magari sarà più complicato gestire le GRID x lo scorrimento?!
luca
> Be questa mi sembra una risposta molto sensata anche se mi viene da
> pensare .......con microsoft......
> o si ha un supporto che fa pena .....ho ti costa un botto
> invece se ho capito bene con FB e/o Postgre bisogna affidarsi ai forum
> e alla bontà altrui
professionale a pagamento anche per firebird. Vedi:
http://www.firebirdsql.org/en/support/
Se guardi nella colonna di sinistra trovi anche un'azienda italiana che
tra l'altro ha anche organizzato l'ultima firebird conference in Italia
qualche anno fa.
Alberto Salvati
RISPONDERE A POST DEL NG.
> Ho visto Flamerobin e vedo che da la possiblità di creare "a mano col
> mouse" i campi nella tabella
> Se volessi creare un DB da delphi direttamente andando a scrivere a
> mano l'elenco dei campi ?
PERCHE' AUTOFUSTIGARSI A SCRIVERE DEL CODICE CHE OVVIAMENTE ANDRA'
TESTATO QUANDO ESISTONO STRUMENTI GIA PRONTI E TESTATI CHE FANNO
QUELLO CHE SERVE? FORSE NON HAI DI MEGLIO DA FARE?
> Il dubbio era proprio sulla velocità di ricerca su tali indici, se ho
> 100 campi dovrei creare 100 indici .... my god
OPPURE PUOI POSTARE SU UN NG DEDICATO AI DB E CHIEDERE LUMI SUL XCHE
USARE UN DB C/S AL POSTO DI UN DB FILE/SERVER.
>
> ehehe no sto cercando la soluzione migliore
> ancora non capisco il motivo nel voler scegliere 1 unico DB anziche 4
> e proporre 1 DB con 4 tabelle
IN ALTERNATIVA PUOI DECIDERE DI "RAGAZZI..RESTA TUTTO COSI..E FANCULO
ORACLE, SQLSERVER, SYBASE, FIREBIRD, POSTGRES..."
TANTO, MO LE COSE FUNZIONANO, GIUSTO? E QUINDI CHE KAZ TE NE FOTTE DI
CAMBAIRE DB???
> > > Mi è stato anche detto che i DB relazionali non si sposano bene con lo
> > > scorrimento in una grid anche se non ne capisco il motivo.
E PRP STAMATTINA UN IN TRENO RACCONTAVA DI AVER AVUTO MANDATO DA GESU
CRISTO DI PRENDERE IL POSTO DI RATZINGER.
POI C'E' L'ULTIMA...IERI SONO STATO CATTURATO DAGLI ALIENI..HO VISTO
SATURNO DA VICINO.
...
A.
Alberto Salvati
A.
ACSH
> L'ALTRO IERI UN AMICO MI HA DETTO CHE SI E' SCOPATO NAOMI CAMPBELL.
(o forse mio cuggggino è cornuto?)
morde
> Se guardi nella colonna di sinistra trovi anche un'azienda italiana che
> tra l'altro ha anche organizzato l'ultima firebird conference in Italia
> qualche anno fa.
Enrico 'Henryx' Bianchi
> invece se ho capito bene con FB e/o Postgre bisogna affidarsi ai forum
> e alla bontà altrui
problema e` che, soprattutto in Italia, vengono recepite male dalle aziende
che dovranno usare il prodotto in ambiente di produzione
Enrico
Enrico 'Henryx' Bianchi
> Ho cambiato molte aziende ma non ho mai sentito di contatti con i
> relativi produttori per avere supporto.
Nelle aziende per cui ho fatto il consulente, c'era sempre un consulente
Oracle chiamato per i piu` disparati motivi (e.g. lanciare le statistiche
del database). Anzi, un contratto di assistenza Oracle non fu affidato a noi
perche` all'epoca non avevamo alcuna figura certificata su tale database
Enrico
Enrico 'Henryx' Bianchi
> Che si può tradurre in "non abbiamo tempo da perdere imparando un nuovo
> database". Tipico..
Enrico
Enrico 'Henryx' Bianchi
> Tutti i DB condividono le informazioni sugli uffici, ad
> esempio.
genere hai uno spreco di spazio non indifferente, in quanto lo stesso dato si ripete per sei volte. Personalmente, risolverei la
cosa in due modi:
1) Accorperei i database in un unico solo e rinominerei tutte le tabelle in
modo che abbiano un prefisso che ne specifichi il settore;
2) Utilizzerei le query cross database (vedi http://www.firebirdfaq.org/faq16/ e
http://www.firebirdsql.org/file/documentation/release_notes/html/rlsnotes251.html#rnfb25-psql-exctstmnt )
Da questo punto di vista, SQL Server, Oracle o PostgreSQL hanno risolto la cosa introducendo gli schemi (anche MySQL permette
query per database, ma da quello che so solo per quelli presenti nell'istanza)
Enrico 'Henryx' Bianchi
> E lo so.... se però posso "progettare" con informazioni del tipo : se
> un DB ha 10 tabelle , indipendentemente dal resto e dal numero di
> indici , sarà più lento di un DB che ne ha 5 .........allora mi regolo
> di conseguenza
performante, mentre ho un database con due tabelle dannatamente lento
> Il dubbio era proprio sulla velocità di ricerca su tali indici, se ho
> 100 campi dovrei creare 100 indici .... my god
problemi di prestazioni. Per capirci, gli indici vanno fatti con criterio
> un file di testo che rappresenta il db + un file di testo che
> rappresenta 1 solo indice principale ,
tabella
> ancora non capisco il motivo nel voler scegliere 1 unico DB anziche 4
> e proporre 1 DB con 4 tabelle
di scatola di cereali che hai in casa quando invece ne basta una. Detto
questo, ti consiglio decisamente di farti affiancare da un db developer
nella riprogettazione dell'applicativo (la cosa piu` evidente e` che questo
thread ha dimostrato che non hai alcuna idea di cosa stai parlando)
Enrico
Enrico 'Henryx' Bianchi
> x Henryx .. cosa intendi per "trigger su vista" ....nel caso di
> partizionamento logico "per anno"
determinate operazioni nel momento in cui si verifica uno specifico evento
(e.g. l'inserimento di un record sulla tabella). Nel caso di un
partizionamento logico, al momento di inserire i dati sulla vista, il
trigger spostera` l'inserimento dei dati sulla tabella corretta
> credi tra l'altro che le prestazioni sulle ricerche aumentino
> separando gli anni in diverse tabelle ?
utile solo quando sulla tabella c'e` una mole considerevole di dati (e.g. >
5mln di record), negli altri casi e` solo un inutile overhead
> mi viene un dubbio, si puo creare una nuova tabella da una
> preesistente e distinguerla per anno ?
fatture_2009
> - la preghiera delle copie quotidiane la pratico anch'io da anni
> ma ... nessuno a parte aziende di "grosse dimensioni" spendono risorse
> nel addestrare qualcuno ALMENO per controllare quotidianamente che
> vengano fatte
un'azienda destinata a fallire. Inoltre, vi sono migliaia di software che
permettono di automatizzare il backup dei dati senza dover mettere in piedi
costose infrastrutture
> ....quindi a
> mio modesto parere le copie non sono una soluzione ad un DB
> inaffidabile e che perde i dati
deve perdere dati. Di conseguenza, puoi tranquillamente installare un RDBMS,
creare il database ed automatizzare il suo backup tramite gli appositi
strumenti
> sto solo confrontandomi con
> qualcuno che ne sa piu di me e mi puo dirigere con qualche consiglio
> verso un DB da installare e testare
> Devo fare un corso di progettazione DB .......se lo trovo.
concetti e` indipendente dal motore utilizzato. Inoltre questa e` una cosa
che devi decisamente fare, altrimenti non arriverai da nessuna parte
> - i possibili valori dei campi stringa da 75 caratteri sono INFINITI
> visto che si tratta di testo libero e non di campi da compilare a
> mezzo tabelle preconfigurate.
> E' cosi problematico aggiungere un campo in una tabella in un DB?
> (considerando che fortunatamente ho la possibilità di avere dei fermo
> macchina visto che le mie applicazioni non sono usate (purtroppo) da
> banche/telecom/etc) ?
> Se ho 1 db per le fatture e 1 db per le pratiche quali sono le
> controindicazioni nell'avere 2 db separati e leggere i record nei 2 DB
> x scambiare parzialmente alcuni dati ?
dei dati al gesu` bambino che piange
> suggerimenti (anche a questo servono i forum .no ?)
> C'è qualcuno che ha un esempio pratico di una necessità che lo ha
> spinto ad avere un unico DB per fatture e pratiche ? (parlo di fatture
> e pratiche solo x esempio)
separati devi come minimo gestire lato client le query inter database, e non
sempre e` una cosa semplice o fattibile
> Questo l'ho capito che lo scorre lui .......ma quanto impiegherà????
Enrico
Warp10
> Warp10 wrote:
>
>> Tutti i DB condividono le informazioni sugli uffici, ad
>> esempio.
>
> Giusto un consiglio. Se non ho capito male, tu hai sei database in cui vi sono replicati gli stessi dati.
Ho un DB che si potrebbe definire "principale" dove sono memorizzati,
tra tante altre cose, gli uffici ognuno con un proprio ID.
Negli altri cinque DB non ho altro dato che identifica l'ufficio che l'ID.
Nessuna ridondanza, se non questa.
Warp10
> - la preghiera delle copie quotidiane la pratico anch'io da anni
> ma ... nessuno a parte aziende di "grosse dimensioni" spendono risorse
> nel addestrare qualcuno ALMENO per controllare quotidianamente che
> vengano fatte e ....puntualmente..quando serve la copia ...ci si
> accorge che l'ultima è di 1 mese fà .....se tutto va bene ....quindi a
> mio modesto parere le copie non sono una soluzione ad un DB
> inaffidabile e che perde i dati
Esistono dei meccanismi automatici per fare il backup del tuo db. Non si
deve "pregare" nessuno.
Per FB (almeno per la versione 1.5 che uso io) c'è GBAK al quale basta
passare i parametri corretti e fa tutto lui. Lo metti in esecuzione
automatica ogni giorno a mezzanotte ed il gioco è fatto.
Certo, il server deve essere acceso e così anche il computer sul quale è
presente il disco su cui fai la copia (non vorrai mica fare la copia su
un HD dello stesso server, vero? :) ), ma a quel punto ti sei tutelato
completamente dalla tua parte.
morde
> Per FB (almeno per la versione 1.5 che uso io) c'è GBAK al quale basta
> passare i parametri corretti e fa tutto lui. Lo metti in esecuzione
> automatica ogni giorno a mezzanotte ed il gioco è fatto.
su un server di produzione:
http://sites.google.com/site/gbakscheduler/home
scritto da un programmatore italiano!
giovanni.v
Il primo elencato č a mio parere eccellente.
Se non vado errato č stato pubblicato in italiano anche da Mondadori
nella collana portatili con il titolo "SQL"... della serie la stampa e
la presentazione fanno schifo ma il contenuto č quello e per una decina
di euro č il caso di dire che li vale tutti, anzi molto di piů.
--
Design for the future, because it will be here sooner than you think.
(C) Eric S. Raymond, from "The Art of Unix Programming"
alessandro f
> Cerchero' di essere, chiaro, inequivocabile e sintetico:
>
> 0) DEVI CHIARIRTI BENE LE IDEE TRA IL CONCETTO DI "DB" E QUELLO DI
> "TABELLA".
> Quella delle fatture, dei clienti, dei fornitori, dei codici iva,
> delle plusvalenze iva sono TABELLE.
> Un db clientr/server e' grosso modo un insieme di tabelle, trigger,
> indici, stored procedure.
> 1) FARE QUERY SU PIU' DB DIVERSI NON E' UNA COSA CHE TUTTI I DB FANNO.
Si l'ho capito. Sto cercando di capire se mi conviene o no separarne
alcune e tutto cio dipende dalle query che dovrò andare a fare
Diciamo che non avro' bisogno di fare query sul DB fatture "in
relazione" al DB DDT
poichè "credo" mi basta avere nel record fatture il numero di DDT e
vicerversa senza dover fare query e quindi potermi "permettere" di
*separare*
Forse ho capito che il motivo vero per cui in tanti mi suggeriscono di
non separe è proprio per i casi in cui si necessita di query su
tabelle collegate tra loro da una relazione specifica. Ipotizzando che
l'unica relazione sia "in_record_1_DBfattura" c'è un campo con il
numero di DDT (e questa è la mia unica ipotizzabile relazione)
potrei pensare di non necessitare di 1 DB unico
> 2) AVERE PIU' DB NON TI SERVE AD UN KAZEN
"qualcuno" dice che su numeri elevati ci potrebbero essere differenze
di prestazioni ma è tutto opinabile in relazione al server , al numero
di record ETC
> 3) L'UNICO MODO CHE HAI PER RENDERTI CONTO DI PERSONA DELLE
> PERFORMANCE E' CREARE UN DB CON UNA TABELLA SIMILE A QUELLA PIU'
> GROSSA CHE GESTISCI ADESSO E SU DI ESSA CREI DEGLI INDICI SUI CAMPI
> CHE TI SERVONO PER LA RICERCA. POI GLI BUTTI DENTRO CON UNA APP
> SCRITTA AL VOLTO 600.000 RECORD E POI PROVI A FARE DELLE QUERY. Ti
> segni i tempi. Poi, riavvii la macchina e rifai le prove.
infatti quello che dovrò fare
saluti
alessandro f
> MI FA MOLTO, MA MOLTO INCAZZARE QUANDO MI SCRIVONO IN PRIVATO PER
> RISPONDERE A POST DEL NG.
allora mi spiace ...... mi sa che ti ho fatto incazzare per mio
errore
pensavo che cliccando su "rispondi all'autore" venisse cmq
visualizzato nel NG tutto !! :)
> MA PERCHE', MAREMMA TROIA? PERCHE' COMPLICARSI LA VITA?
> PERCHE' AUTOFUSTIGARSI A SCRIVERE DEL CODICE CHE OVVIAMENTE ANDRA'
> TESTATO QUANDO ESISTONO STRUMENTI GIA PRONTI E TESTATI CHE FANNO
> QUELLO CHE SERVE? FORSE NON HAI DI MEGLIO DA FARE?
mentre progetti il DB
io invece considero la mia esigenza e conoscendola meglio penso a cio
che potrebbe essere meglio :
ho già un file di testo con tutte le specifiche e anzichè dover
riscrivere tutto a mano , con un copia incolla piu qualche
aggiustamento sarò sicuramente più veloce...
> > Il dubbio era proprio sulla velocità di ricerca su tali indici, se ho
> > 100 campi dovrei creare 100 indici .... my god
>
> NO. E SAI XCHE? SE NON LO SAI LO SCOPRIRAI STUDIANDO E PROVANDO.
> OPPURE PUOI POSTARE SU UN NG DEDICATO AI DB E CHIEDERE LUMI SUL XCHE
> USARE UN DB C/S AL POSTO DI UN DB FILE/SERVER.
> NON CAPISCI? CAPIRAI STUDIANDO E PROVANDO.
> IN ALTERNATIVA PUOI DECIDERE DI "RAGAZZI..RESTA TUTTO COSI..E FANCULO
> ORACLE, SQLSERVER, SYBASE, FIREBIRD, POSTGRES..."
> TANTO, MO LE COSE FUNZIONANO, GIUSTO? E QUINDI CHE KAZ TE NE FOTTE DI
> CAMBAIRE DB???
costruttiva" cmq grazie lo stesso
> L'ALTRO IERI UN AMICO MI HA DETTO CHE SI E' SCOPATO NAOMI CAMPBELL.
> E PRP STAMATTINA UN IN TRENO RACCONTAVA DI AVER AVUTO MANDATO DA GESU
> CRISTO DI PRENDERE IL POSTO DI RATZINGER.
> POI C'E' L'ULTIMA...IERI SONO STATO CATTURATO DAGLI ALIENI..HO VISTO
> SATURNO DA VICINO.
alessandro f
> Warp10 wrote:
> > Tutti i DB condividono le informazioni sugli uffici, ad
> > esempio.
>
> Giusto un consiglio. Se non ho capito male, tu hai sei database in cui vi sono replicati gli stessi dati. In una situazione del
> genere hai uno spreco di spazio non indifferente, in quanto lo stesso dato si ripete per sei volte. Personalmente, risolverei la
> cosa in due modi:
>
> 1) Accorperei i database in un unico solo e rinominerei tutte le tabelle in
> modo che abbiano un prefisso che ne specifichi il settore;
> Da questo punto di vista, SQL Server, Oracle o PostgreSQL hanno risolto la cosa introducendo gli schemi (anche MySQL permette
> query per database, ma da quello che so solo per quelli presenti nell'istanza)
riferimenti tra i vari DB
ad esempio, nel DB fatture in un record c'è scritto che la fattura
1234 è stata emessa a fronte del DDT nr. 432
Cio che è identico in tutti i DB è la tabella clienti ed altre tabelle
relative a codici in comune come ad esempio potrebbero essere l'elenco
delle città italiane , le condizioni di trasporto , etc
alessandro f
> alessandro f wrote:
> > E lo so.... se però posso "progettare" con informazioni del tipo : se
> > un DB ha 10 tabelle , indipendentemente dal resto e dal numero di
> > indici , sarà più lento di un DB che ne ha 5 .........allora mi regolo
> > di conseguenza
>
> No. Per farti capire, ho un database di 60 e rotti tabelle decisamente
> performante, mentre ho un database con due tabelle dannatamente lento
>
> > Il dubbio era proprio sulla velocità di ricerca su tali indici, se ho
> > 100 campi dovrei creare 100 indici .... my god
>
> No. Indicizzare in modo selvaggio un database rischia solo di creare
> problemi di prestazioni. Per capirci, gli indici vanno fatti con criterio
>
> > un file di testo che rappresenta il db + un file di testo che
> > rappresenta 1 solo indice principale ,
>
> Il file di testo che tu dici rappresentare il database rappresenta piu` una
> tabella
>
> > ancora non capisco il motivo nel voler scegliere 1 unico DB anziche 4
> > e proporre 1 DB con 4 tabelle
>
> Perche` non ha senso. E` come se tu utilizzassi una credenza per ogni tipo
> di scatola di cereali che hai in casa quando invece ne basta una.
>Detto
> questo, ti consiglio decisamente di farti affiancare da un db developer
> nella riprogettazione dell'applicativo (la cosa piu` evidente e` che questo
> thread ha dimostrato che non hai alcuna idea di cosa stai parlando)
>
> Enrico
alessandro f
solo proprio pochi che lasciano acceso il server
la notte , forse questo anche dovevo aggiungere nel post iniziale per
evitare equivoci "di visioni" personali
Cmq è sicuro utile cosa (e necessaria!!) quando si può fare
alessandro f
> > - i possibili valori dei campi stringa da 75 caratteri sono INFINITI
> > visto che si tratta di testo libero e non di campi da compilare a
> > mezzo tabelle preconfigurate.
>
> Questo e` male, molto ma molto male
una esigenza reale"
quindi devo adeguarmi
> > suggerimenti (anche a questo servono i forum .no ?)
>
> Questo non e` un forum
ho sbagliato forse "espressamente il termine specifico" ma di
"discussioni si tratta" , e infatti se rileggo un po di post...... mi
sembra anche "di più".......
> Come prima, dipende da un fottiliardo di fattori
>
compilare i campi da 75 caratteri, e non posso creare tot indici per
quanti sono questi campi da 75char e devo per forza leggerli uno ad
uno ....... chiedere ad un motore DB che pur evoluto e su superserver
che sia ..... da piu client , una ricerca del genere su TABELLE
diverse che sono nello stesso DB ...... secondo me sono dolori ...ma
vale il suggerimento di Alberto.......... devo solo provare o chiedere
in un altro ***forum*** a chi ha già fatto qualche test simile (a
parità di esigenze)
forse il mio post iniziale doveva essere improntato in questo modo x
evitare inutili discussioni.........
Warp10
> Cio che è identico in tutti i DB è la tabella clienti ed altre tabelle
> relative a codici in comune come ad esempio potrebbero essere l'elenco
> delle città italiane , le condizioni di trasporto , etc
in *ogni file di testo*?
Dimmi che non è così, dimmi che ho capito male.
Cosa fai se ti viene cambiata la partita IVA, il numero di telefono,
l'e-mail, la ragione sociale di un cliente? Spazzoli tutti i file di
testo per replicare la modifica?
Beh, se è così è di certo ridondante. :)
Enrico 'Henryx' Bianchi
> Cio che è identico in tutti i DB è la tabella clienti ed altre tabelle
> relative a codici in comune come ad esempio potrebbero essere l'elenco
> delle città italiane , le condizioni di trasporto , etc
Enrico
Enrico 'Henryx' Bianchi
> solo proprio pochi che lasciano acceso il server
> la notte
backup (un negozio sta aperto 8 ore lavorative), ma farlo
Enrico
Enrico 'Henryx' Bianchi
> Secondo me una risposta c'è già
qualche post fa': non hai idea di come funziona un vero RDBMS (perche`,
ricordiamolo, quelli che tu chiami "database" non sono altro che file di
testo strutturati con un file indice fatto chissa` come[1]). Le uniche
soluzioni a questa situazione sono tre:
- O paghi qualcuno per farti progettare una base dati come si deve (perche`
un indice per ogni campo di una tabella non s'e` mai sentito);
- O ti metti a studiare come funziona un RDBMS (la base SQL e` valida
praticamente per tutti);
- O lasci perdere e trovi una soluzione alternativa al tuo problema (anche
se dubito che esista).
Il tutto senza cattiveria, ovviamente
Enrico
alessandro f
No .... ho un file clienti , e lo stesso viene usato in tutte le
procedure che ne fanno uso
infatti pensando al nuovo progetto avevo in mente di avere un unico
*DB* per tutte le tabelle comuni e meno popolate , tipo clienti, città
etc
mente invece quello delle fatture di ridondande rispetto a quello dei
DDT forse ha la p.iva+rag.soc+ind
effettivamente questi 5 dati si ripetono, avrei potuto inserire solo
il codice cliente evvia ma ho preferito lasciare all'utente la
possibilità di inserirlo a manina nel caso fosse un cliente una tantum
senza doverlo inserire nel file di testo (=DB) principale ......
a parte questo , in fatture ho il numero relativo di DDT , di BOLLA ,
etc , penso che una ventina di byte me li posso permettere :)
alessandro f
non ci sono orari d'ufficio dove dalle 13 alle 14 sono tutti a
pranzo ........
alessandro f
alessandro f
scegliere da me in base alle mie reali esigenze anzichè lasciarle
ipotizzare da altri in base alle proprie necessità che non
necessariamente coincidono con le mie
sopratutto per chi non ha mai "testato" le velocità/accessi/ricerche
che ho in mente di realizzare
quindi vale il suggerimento di Antonio , provero' da me
In ogni caso l'obiettivo primario del mio post era un suggerimento sul
DB da scegliere e ora sono orientato verso FB
Scriverò un altro post su un *forum* di chi è specializzato in
sviluppo DB : )
...per chiedere lumi sulle prestazioni e sulla possibilità di avere DB
separti con un unico DB per le tabelle in comune , specificando :
visto che non ho *relazioni particolari* e pochi dati ridonandanti
quale è il problema a tenerli separati ? ......lo svantaggio di
avviare diverse sessioni per un backup ?
c'è un vantaggio in termini di velocità ?
grazie a tutti cmq !!
Alberto Salvati
A.
Enrico 'Henryx' Bianchi
> Mahh... sarebbe utile un esempio pratico.......
CREATE TABLE clienti (id_cliente INTEGER PRIMARY KEY,
nome_cliente VARCHAR(30)
);
CREATE TABLE fatture (num_fattura INTEGER,
data_fattura DATE,
importo INTEGER,
id_cliente INTEGER REFERENCES client(id_cliente),
CONSTRAINT pk_fatture PRIMARY KEY(num_fattura,
data_fattura)
);
In altre parole, sul database ho una tabella clienti e n tabelle (e.g.
fatture) che si referenziano alla tabella clienti. Nota il vantaggio di
avere tutto in un database: eventuali integrita` di dati sono fatte dal
database stesso (e.g. se id_cliente non esiste sulla tabella clienti, il
database non permette l'inserimento dei dati e ritorna un errore), che e`
poi la normale gestione di tali operazioni (in altre parole, ho implementato
sul mio schema quella che viene chiamata integrita` referenziale)
Enrico
Enrico 'Henryx' Bianchi
> Si può fare anche mentre l'utente usa il DB ?
commit (e, sempre ovviamente, questo vale per tutti i motori RDBMS in
circolazione)
> non ci sono orari d'ufficio dove dalle 13 alle 14 sono tutti a pranzo
Enrico
Enrico 'Henryx' Bianchi
> Certo , lo so , preferisco la soluzione nr 2 poichè preferisco
> scegliere da me in base alle mie reali esigenze anzichè lasciarle
> ipotizzare da altri in base alle proprie necessità
> sopratutto per chi non ha mai "testato" le velocità/accessi/ricerche
> che ho in mente di realizzare
> visto che non ho *relazioni particolari* e pochi dati ridonandanti
> quale è il problema a tenerli separati ?
> ......lo svantaggio di
> avviare diverse sessioni per un backup ?
> c'è un vantaggio in termini di velocità ?
database comporta una spesa in termini sia di risorse occupate che di tempo,
capirai ancora di piu` perche` la tua ostinazione non ha senso
Enrico
alessandro f
Sto "studiando".....relazioni ..e integrità referenziale ...e quindi
inizio a capire un bel po di cose...
non volevo essere presuntuoso , soltanto riflettevo sul fatto che le
mie esigenze nessuno può conoscerle meglio di me ........
Ho capito o quasi .....i motivi per avere un DB unico....... però
sarei disposto a rinunciare ad "alcune cosette" in nome della
velocità...... e qui .....devo solo testare ....
Qualche suggerimento per tools per progettare il DB ?
Se ho capito bene FB propone software di terzi quindi non ha tools
visuali propri
Quello che non sono riuscito a trovare in rete è qualche buon corso
che tratta di creazione indici , tutti coloro che parlano di SQL (in
maniera semplice) si fermano prima !!!
La ricerca full text su tutti i campi è quella che mi rende
ostinato ..... non potrò usare un indice e quindi ....dovendo scorrere
tutti i record del DB fatture o DB XXXX senza poter estrapolare
NESSUNA relazione specifica TEMO per le prestazioni di una SELECT
senza nessuna WHERE XX=YY o meglio di una SELECT (e ora me la invento
io ) WHERE ALL FIELDS CONTAIN YXZ (in formato testo libero)
alessandro f
Se ho un DB unico con FATTURE e DDT ed ho clienti che usano solo
FATTURE e clienti che usano ENTRAMBI
e credo un DB con relazione tra le tabelle , avrò per il cliente un DB
FATTURE con inutili record relativi al DB DDT che non verrà mai usato
l'unica soluzione sarà di avere a disposizione 2 DB diversi da
installare in base all'occorrenza di installazione oppure potrei
gestire da codice l'inizializzazione del DB all'atto della
installazione?
luca
> Ho capito o quasi .....i motivi per avere un DB unico....... però
> sarei disposto a rinunciare ad "alcune cosette" in nome della
> velocità...... e qui .....devo solo testare ....
spezzettando il database. Puoi cominciare a porti il problema quando il
database cominciarà a superare qualche giga.
> Qualche suggerimento per tools per progettare il DB ?
> Se ho capito bene FB propone software di terzi quindi non ha tools
> visuali propri
prendi quella a pagamento che ha diverse cose interessanti (per esempio
per analizzare le performance).
> Quello che non sono riuscito a trovare in rete è qualche buon corso
> che tratta di creazione indici , tutti coloro che parlano di SQL (in
> maniera semplice) si fermano prima !!!
> La ricerca full text su tutti i campi è quella che mi rende
> ostinato ..... non potrò usare un indice e quindi ....dovendo scorrere
> tutti i record del DB fatture o DB XXXX senza poter estrapolare
> NESSUNA relazione specifica TEMO per le prestazioni di una SELECT
> senza nessuna WHERE XX=YY o meglio di una SELECT (e ora me la invento
> io ) WHERE ALL FIELDS CONTAIN YXZ (in formato testo libero)
anche senza indici. Eventualmente puoi concatenare i tuoi campi in uno
fittizio (che usi solo per le ricerche) e fare la where solo su quello
in modo da evitare una sfilza di OR. Ma - come ti è stato detto più
volte - bisogna provare.
morde
> Il 26/10/2011 11:12, alessandro f ha scritto:
Attenzione al link: quell'edizione *probabilmente* è obsoleta.
Qui si trovano le versioni aggiornate, con un supplemento sulla v.2 del
motore: http://www.ibphoenix.com/products/books/supplement
ciao
Warp10
> La ricerca full text su tutti i campi č quella che mi rende
> ostinato
Non so se lo hai gią detto prima ma quale informazione contengono questi
campi di testo?
luca
>> http://www.apress.com/9781590592793
>
> Attenzione al link: quell'edizione *probabilmente* è obsoleta.
punto di partenza. Per aggiornarsi poi è sufficiente leggersi le release
note delle versioni successive.
P.S. Comunque grazie! non sapevo di quel "book supplement" me lo prendo
al volo :)
Enrico 'Henryx' Bianchi
> Qualche suggerimento per tools per progettare il DB ?
Enrico
alessandro f
di essere presuntuoso......
o quantomeno immaginare che chi risponde o non ha capito o non ha
letto....o mi sono spiegato io male
ripeto :
10.000 record composti da 100 campi di cui 25 sono 75caratteri di
testo e io....devo chiedere al motore :
"mi trovi tutti i record che contengono almeno la parola "UNA PARTE"
in una qualsiasi parte dei 25 campi da 75 char dove non ho creato
indici .... e questa cosa deve essere fatta leggendo 10,000
record ..... dire che è "istantaneo" .....MAHHHHHHHHHHH