5 ragioni per cui bisognerebbe usare PostgreSQL
Dopo una piccola pausa dovuta ai miei nuovi studi, un gustoso articolo sui perchè PostgreSQL sia da adottare. A fine articolo fonte e link per il download di PostgreSQL.
Nell’arco degli ultimi due anni Oracle, IBM e Microsoft hanno rilasciato versioni gratuite dei loro RDBMS “Ammiragli”, una mossa senza precedenti se pensiamo ad un paio di anni indietro. Mentre i rispettivi rappresentanti hanno dichiarato che la mossa è stata decisa per conciliare gli interessi dei loro utenti, è piuttosto chiaro che il rilascio è avvenuto per far fronte alla continua pressione delle alternative open source come MySQL e PostgreSQL.
Mentre il tasso di “addozioni” di PostgreSQL continua a crescere, molta gente si stupisce come mai non sia maggiore visto il suo impressionante numero di caratteristiche. Qualcuno può specularci dicendo che molte ragioni per non adottarlo risiedano in fonti non aggiornante o disinformate[..]Eccomi quindi a fornirvi 5 motivazioni in modo da sfatare possibili dubbi su PostgreSQL
Motivazione #1: Non funziona su sistemi operativi Windows
PostgreSQL supporta da molto tempo ogni moderno sistema operativo di tipo Unix, sono disponibili inoltre dei ports per Novell NetWare e OS/2. Con la release 8.0 , il supporto di PostgreSQL per tutti i sistemi mainstream è completo includendo il port per Windows.
L’installazione è oltretutto migliorata facendo si’ che il wizard sia simile a quello dell’installazione di Microsoft Word o Quicken.
Motivazione #2: Nessun tool di sviluppo …
Diversi utenti poco famigliari con i progetti open source pensano che gli amministratori di DB vadano a gestirli tramite una lunga serie di “esoterici” comandi da shell. In effetti, mentre PostgreSQL trae vantaggio da un ambiente a linea di commando, esistono diversi tools grafici per compiere attività come l’amministrazione oppure il design di un database.
La seguente lista riassume i tools disponibili ai sviluppatori PostgreSQL:
Modellazione di Database: Visual Case e Data Architect.
Amministrazione e sviluppo: pgAdmin III , Navicat PostgreSQL, phpPgAdmin.
Reporting: Crystal Reports, Cognos ReportNet e JasperReports.
Motivazione #3: PostgreSQL non supporta il mio linguaggio
Per smentire anche ciò, eccovi un elenco:
C++, C#, JDBC, Perl, PHP, Python, Ruby, Tcl, Ada, Common Lisp e Pascal ….
Motivazione #4: Non c’è nessuno con cui prendersela quando qualcosa non funziona
La concezione erronea che l’ open source sia affetto da una mancanza di supporto tecnico è curiosa, specie quando una delle tante definizioni di supporto consiste nell’avere qualcuno con cui prendersela quando qualcosa non funziona..
Potete trovare la risposta ad un gran numero di richieste di supporto nel manuale di PostgreSQL, che consiste in 1,450 pagine di documentazione dettagliata su ogni aspetto del database.
La documentazione è disponibile per una consultazione online o per il download in formato PDF. Richieste di aiuto urgenti possono avvenire tramite il vasto numero di NewsGroup (tramite Google groups ad es.) mentre risposte immediate posson essere ottenute dai canali IRC (irc.freenode.net #postgresql?).
Motivazione #5: Non hai ciò che non paghi..
Se richiedi un database SQL standards-compliant con tutte le caratteristiche di un prodotto di classe enterprise, capace di immagazzinare terabyte di dati anche in condizioni di forti carichi di lavoro , le chance per cui PostgreSQL assolverà questo compito saranno altissime
Che dire? Un altro luogo comune sfatato!
Commento di Anonymous • 16 Marzo 2006:
Bell’articoletto, ma la motivazione 4 purtroppo non ha ancora molte possibilità di essere presa sul serio per la semplice ragione che molte ditte preferiscono scaricarsi la responsabilità se qualcosa va male.
L’ho visto molte volte nella vita lavorativa, “La database non funziona?” colpa di XYZ, non nostra, quindi non potete chiederci di pagare le penali”, e capita piu’ spesso di quello che si creda. Nel caso che si adotti una soluzione Open Source (che sia PostgreSQL, Linux, o qualunque altro prodotto) la prima preoccupazione dei responsabili di progetto è “su chi possiamo rigettare la responsabilità se sorgono problemi?” e chiaramente la risposta non è Linus Torvalds, non è neppure “La comunità”, è “Nessuno, i responsabili siamo solo noi!”.
Quando un capo progetto sceglie una soluzione OpenSource che poi si rivela inadeguata o buggata rischia di pagare la sua audacia molto cara, se invece capita con un prodotto MS o di qualche altro grosso fabbricante, o gli rigetta la responsabilità o si rifugia dietro “comunque non avevo molta altra scelta, o era quel prodotto oppure i rischi sarebbero stati troppo elevati”, oppure un “se neppure MS riesce a farlo correttamente chissà cosa sarebbe capitato se avessi scaricato un prodotto OS su qualche sito web”.
Ogni volta ci si urta ai timori dei vari capi progetto che preferiscono avere sempre una via di fuga per evitare di assumersi le proprie responsabilità e nel contempo pure all’ignoranza dei dirigenti che considerano normale questo tipo di atteggiamento e non fanno nulla per impedirlo.
Commento di Anonymous • 16 Marzo 2006:
Al solito il problema dei capi-progetto e’ non riuscire a parlare col cliente in un’ottica che vada oltre il progetto (nella fattispecie i costi d’acquisto/manutenzione d’un DB “non open”).
Commento di Anonymous • 16 Marzo 2006:
pur essendo un amante del software open source non riesco a raccomandarlo per applicazioni core business di grossi clienti.
se un database oracle presenta bug critici è possibile avere una patch ad-hoc in tempi relativamente decenti.
il supporto si paga ma è comunque efficiente.
vale la stessa cosa per tutti i prodotti open-source?
forse per postgresql si ma sicuramente non per tutti i prodotti open source.
Commento di Matteo • 16 Marzo 2006:
Ti consiglio andare a leggere un post dell’altro mese in cui si va ad analizzare il ciclo patch releases di Oracle (da George OU). Ciò nonostante Oracle rimane lo stesso anche a parer mio un grande database Oracle, ciclo patch releases Ciao da Matteo
Commento di Max • 11 Luglio 2007:
Scusate ma devo costruire un Crystal report con postgres utilizzando vb2005. Nessuno sa come si può fare? Mi da sempre come errore: Provider non supportato.
Grazie per l’aiuto.