Newsgroup: it.comp.os.dibattiti
Titolo: [OT] DBMS di sviluppo: server locale VS server remoto?

Ovvero, preferite un server sulla vostra macchina, per sviluppare, oppure
un server remoto?
Noi abbiamo server remoti, per 2 motivi principali:
Lavoriamo su enormi quantità di dati (alcune tabelle superano
abbondantemente i 2 milioni di record), e i DB sono progettati dagli
analisti.
Questo ci solleva da responsabilità come l'amministrazione di sistema dei
server, la manutenzione dei DB, etc etc, ed inoltre ci consente di testare
tutti i casi d'uso con i medesimi dati, senza dover sincronizzare
periodicamente i db locali, nonchè di segnalare eventuali problemi di
design direttamente agli analisti, e vederli corretti in "diretta".
Dite la vostra!
Raffaele
-- 
Raffaele Castagno
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 oppure un server remoto?
Dipende da quanto occorre violentare i dati di test.
Se magari stai provando una routine di cancellazione dati (o aggiornamento)
mentre i tuoi colleghi stanno cercando di capire perchè un dato da programma
viene diverso rispetto a quello atteso mi sa che sono c...i...


Un server di test,in ufficio, non sempre sincronizzato con i dati reali, ma 
solo un sottoinsieme.
Lavorare con i dati effettivi è troppo rischioso e sopratutto puo causare 
dei problemi di prestazioni a chi stà lavorando.
-- 
Massimiliano G.
www.birreonline.net
God blesses the men who intenvented beer

 viene diverso rispetto a quello atteso mi sa che sono c...i...
Dipende dal tipo di dati. Per esempio, se si stanno trattando dati
relativi a delle ditte, la maggior parte delle operazioni agisce su una
sola ditta, quindi basta scegliere ditte diverse sulle quali lavorare (noi
facciamo cosě...)
Certo, se scrivi le query senza ricordarti di aggiungere la where sono
ceci, ma ho visto fare ai nostri analisti cose che voi umani non potete
immaginare! (ergo: per un'intera giornata i clienti hanno lavorato sul DB
di Test, sul quale anche noi stavamo lavorando, invece che sul DB di
produzione: due DBWonderWoman hanno smanettato fino a rimettere tutto in
ordine...)
Comunque, credo di penda dai casi...


 un server remoto?
Lavoro su Oracle e ovviamente preferisco un database locale, quando 
possibile. Non sempre è possibile sia per ragioni tecniche che per 
ragioni di riservatezza in quanto talvolta contengono dati reali di 
aziende (consenzienti, ma a determinate condizioni).
Le ragioni tecniche non sono tanto legate alla quantità dei dati (tutto 
sommato con i dischi odierni il problema non sussiste) quanto alla 
struttura del db che richiede un dimensionamento in memoria non 
indifferente.
Il problema sistemistico per me non è un peso, francamente oracle su 
windows si manutiene facile e chiaramente nel db di sviluppo non ho 
bisogno di tuning fine. La struttura non la manutengo in quanto 
periodicamente esporto il db centrale e lo importo in locale (dati e 
struttura aggiornati).
Il vantaggio è anche che non sono legato fisicamente al server.

 Il vantaggio è anche che non sono legato fisicamente al server.
Condivido. Da quando siamo passati a Postgres ho apprezzato in modo 
entusiastico la rapidita' con cui si possono esportare interi db, 
separando gli script DML da quelli DDL. In pratica prelevo gli script 
della creazione db e indici, e separatamente i dati. Poi sincronizzo il 
db in locale.
Quindi non comprometto la funzionalita' dei server di produzione, e 
posso mantenere diverse release di sviluppo.