Domanda

Sono stato interessato a 4D SAS 'prodotto per molto tempo, anche se a malapena l'ho toccato in eoni .

Nel considerare quali strumenti utilizzare per lo sviluppo di applicazioni, in particolare uno che richiederà un componente di database, cosa si dovrebbe cercare quando si considerano strumenti open source come MySQL e PostgreSQL vs soluzioni proprietarie come 4D o Pervasive SQL?

Quali esperienze positive (e negative!) ha avuto la comunità SO con vari strumenti DB come 4D, Pervasive, FilemakerPro, ecc?

Qualche brutta esperienza?

È stato utile?

Soluzione

4D è un sistema di database proprietario multipiattaforma MacOS / Windows con varietà sia stand-alone che Client-Server. Faresti bene a confrontarlo con il software Alphafive.com che è solo Windows. Ci lavoro da 17 anni e ha servito molto bene me e il mio dipartimento. Fuori dalla mia testa ...

Pro:

  1. Interfaccia e amp; il codice è strettamente legato al motore di dati che rende lo sviluppo di interfacce utente complesse e multipiattaforma molto veloci e facili.
  2. Il motore di dati relazionale proprietario funziona nativamente su entrambe le piattaforme, insieme alle interfacce client native (ma richiede licenze per più utenti). Le relazioni automatiche sono utili (ma a volte interferiscono).
  3. Può accedere a sistemi esterni tramite SOAP e ODBC e driver SQL (limitato).
  4. Può accedere a 4D da sistemi esterni tramite SOAP o richieste HTTP & amp; pagine Web.
  5. Linguaggio di programmazione procedurale nativo basato su Pascal ed è FACILE da imparare.
  6. Strumento eccellente per i dipartimenti di piccole e medie dimensioni.
  7. L'ultima versione accetta un sottoinsieme di comandi SQL E l'accesso ai dati originali, quindi il record di compatibilità con le versioni precedenti è stato molto buono.
  8. La sicurezza è FACILE in 4D.
  9. Puoi creare soluzioni da distribuire attraverso una varietà di mezzi e non sono limitati dal fatto che MS Access sia installato o meno.

Contro:

  1. Interfaccia e amp; il codice è strettamente legato al motore di dati che può portare a un uso limitato dell'astrazione e "scatola nera" programmazione a meno che tu non lo renda un obiettivo del tuo sviluppo.
  2. Compila un file di struttura monolitica forzando il riavvio per singole correzioni.
  3. Il linguaggio è ancora solo procedurale, il che rende più difficile l'accettazione da parte dei programmatori orientati agli oggetti. Ogni metodo richiede "file" separato in 4D quindi non puoi includere più di una funzione o procedura in una singola routine - ci vorrà un po 'di tempo per abituarsi.
  4. Mentre la società sembra essere in buona forma, in crescita e in via di sviluppo, semplicemente non si sa mai perché mantengono le loro condizioni per sé.
  5. La società non si è mai realmente commercializzata, confidando nella sua base di sviluppatori per spargere la voce e far crescere il prodotto attraverso implementazioni sul sito e aggiornamenti del prodotto. Il sito Web è chiaramente utile solo per gli sviluppatori che già utilizzano il prodotto: non riesce semplicemente ad attirare nuovi utenti.
  6. Gli aggiornamenti del prodotto sembrano sempre concentrarsi su come lo strumento è migliore per gli SVILUPPATORI piuttosto che per i CLIENTI di quegli sviluppatori.
  7. SQL manca di viste, indici composti e altre funzionalità SQL comuni.
  8. Quando un utente richiede un rapporto di specifiche colonne di dati, spesso devo scrivere ancora un altro programma solo per fornire quei dati specifici - non posso sempre semplicemente interrogare i dati e generare un file di testo.
  9. Non gestisce le nuove versioni del sistema operativo con quasi la facilità delle applicazioni basate su browser Web. La versione precedente è interrotta su Mac OS 10.6 e la versione più recente richiede l'ultimo Mac OS 10.6. Nessuna versione è ancora certificata su Windows 7.

Sono stato quasi un anno a studiare ASP.NET e alcune settimane a Ruby on Rails. Mentre gli archivi di dati SQL sono FACILI, l'interfaccia utente è DIFFICILE, ma ne vale la pena quando l'applicazione funziona ancora tramite gli aggiornamenti del sistema operativo. Puoi sempre utilizzare un browser più vecchio se l'ultima versione rompe qualcosa.

Ti consiglio di prendere in considerazione uno di questi, a seconda di quanti fondi hai a disposizione per implementare il progetto - Rails è il più economico dei due. Quindi, QUALSIASI sistema con un browser Web può accedere ai dati e puoi correggere le pagine dell'interfaccia al volo, se necessario, piuttosto che ridurre l'intero sistema in pochi minuti per un singolo, semplice aggiornamento. Tali competenze potrebbero essere più commerciabili in futuro.

Altri suggerimenti

Difficile fare un elenco rilevante di pro e contro senza un contesto.

Il mio consiglio sarebbe il seguente: quando prendi la decisione di utilizzare un database proprietario, assicurati che questa decisione sia basata su fatti concreti e non semplicemente un interesse tecnico per uno strumento esotico. Metti in equilibrio i vantaggi dell'utilizzo del database proprietario e i vantaggi di una soluzione non proprietaria.

La risposta è diversa da sistema a sistema.

Un prerequisito è che il sistema sia ben identificato, con un ambito chiaro, un'evoluzione abbastanza prevedibile, in modo che i risultati dell'analisi siano solidi. Quindi, se la tua soluzione proprietaria offre un vero vantaggio al tuo sistema, sei a tuo agio con il supporto e puoi permetterti il ??costo complessivo, dovresti essere un buon candidato per la soluzione proprietaria.

Dirò solo una cosa. Guarda il " effettivo " costo della tua decisione .. La maggior parte dei sistemi di database proprietari sono solo Windows .. o talvolta Mac / Windows.

Ciò significa che oltre a pagare un bel po 'di soldi per il sistema di database, è necessario anche pagare una buona quantità di denaro su un sistema operativo Server per eseguirlo ...

Inoltre, confronta il sistema di database con le attuali soluzioni open source. Ne vale davvero la pena? Dopo essermi trasferito da Microsoft SQL Server (che ha un'edizione gratuita, ma comunque) a PostgreSQL, sono stato sbalordito dal fatto che la gente pagasse così tanto per SQL Server .. Voglio dire, Postgres per me è molto più pulito e la maggior parte funziona esattamente come ti aspetteresti (diversamente da alcune sintassi del server SQL) e ha più funzionalità integrate (programmare i processi memorizzati in Ruby qualcuno?)

Quindi, fondamentalmente, confrontate il proprietario con il software open source e decidete quale prendere per prezzo totale (compreso il sistema operativo) e set di funzionalità ..

  • Pro di azzeramento su qualsiasi DB: ha buone funzionalità non portatili che ti aiutano a fare le cose
  • Contro di azzeramento su qualsiasi DB: a volte è appropriato un DB diverso (ad esempio eseguendo i test con istanze SQLite in memoria), ma quell'opzione è ora chiusa
  • Contro di un DB commerciale proprietario: se hai bisogno di molte istanze, i costi di licenza possono ucciderti

Considera le seguenti domande:

  • Quanto è facile (o difficile) apportare modifiche alla manutenzione? È probabile che le applicazioni impieghino molto più tempo nella manutenzione di quanto non facciano nello sviluppo, quindi se i cambiamenti sono difficili, il dolore a lungo termine è garantito.
  • Qual è la qualità del supporto? Un sistema ben documentato, proprietario o di altro tipo sarà più facile da utilizzare.
  • Quanto è grande (o piccola) la comunità di utenti? I sistemi con comunità di utenti più grandi significano che più persone chiedono assistenza se e quando le cose vanno male.
  • Quanto sono robuste le capacità di importazione / esportazione di questo sistema di database proprietario?

Ho trovato l'ultimo punto particolarmente utile nel mio primo lavoro a tempo pieno. Il nostro cliente utilizzava CA-Ingres e nessuno in azienda sapeva abbastanza bene scrivere query per convalidare i dati. Quindi mi è venuta l'idea di esportare i dati da Ingres e importarli in MS SQL Server (che conoscevo da un breve periodo presso Sybase Professional Services) in modo da poter scrivere lì le nostre query di validazione. Se fosse stato davvero difficile esportare dati da Ingres, la mia idea non sarebbe stata un'opzione.

Dalla pagina Web di 4D, ho notato che stiamo guardando un ambiente di sviluppo + distribuzione completo, non un database autonomo in quanto tale. Quindi le alternative che potresti vedere includono cose come django, ruby-on-rails, hibernate e altri. La vera domanda, ovviamente, è se il sistema proprietario può farti risparmiare abbastanza denaro facendo la vita del prodotto per giustificare i costi del prodotto. E ciò dipenderebbe dal tipo di risorse umane disponibili.

4D è una buona opzione per le applicazioni verticali. Ho lavorato per un'azienda che utilizzava 4D per creare una cartella clinica e un'applicazione di fatturazione per medici di medicina generale e specialisti. Le funzionalità di progettazione e distribuzione rapide di 4D hanno consentito all'applicazione di muoversi rapidamente con i desideri del mercato e le modifiche legislative alla conservazione delle cartelle cliniche.L'ambiente stesso non era all'avanguardia, ma era integrato, multipiattaforma e molto produttivo.

Se stai entrando in un mercato con un alto livello di blocco dei fornitori e un'elevata barriera all'ingresso, penso che gli ambienti di sviluppo integrati proprietari siano una buona opzione.

In vari punti della mia carriera, ho usato e ottenuto ottimi risultati con FileMaker Pro, FoxPro, 4D e alcuni altri prodotti commerciali. Ora uso principalmente PHP / MySQL e non ho usato le ultime versioni di nessuno dei prodotti.

Mi è sempre piaciuto FileMaker perché la maggior parte delle persone che possono usare un computer possono prelevare FileMaker e progettare i propri sistemi. Non devono conoscere la programmazione o la progettazione del database. Tuttavia, puoi " programmare " FileMaker, inserisci un front-end Web o esegui altre configurazioni più sofisticate, se necessario. Molte volte sono stato "consegnato". un sistema creato in FileMaker da una persona non tecnica che doveva essere trasformato in un sistema di gestione dei dati completo. La parte buona era che tutte le "specifiche" e il flusso di dati era già stato progettato in un sistema. Il prototipo era già stato creato!

4D e FoxPro ho sempre trovato necessaria una certa quantità di conoscenza extra di programmazione e / o database per fare davvero qualsiasi cosa. 4D e amp; FileMaker sono sistemi autonomi davvero completi, non solo sistemi di database. Sebbene abbiano tutti la possibilità di collegarsi ad altri sistemi di database di back-end (ovvero MySQL, Oracle), non è questo il loro punto di forza.

Sul lato negativo, fare sistemi più complessi e dinamici può essere difficile in 4D e Filemaker a causa di tutto ciò che è strettamente accoppiato. A causa del loro costo, vorresti davvero creare più sistemi con loro. Ciò significa che devi davvero " comprarli " per far valere i tuoi soldi.

Il concetto chiave è sempre il rispetto degli standard: se prevedi di utilizzare le funzioni personalizzate e / o speciali di 4D (ma la discussione potrebbe essere molto più generale e coprire qualsiasi altro strumento gratuito o commerciale in natura), beh, basta usarlo e trarne vantaggio.

Non sorprende, ecco perché enormi sistemi DB come Oracle o DB2 di IBM in passato sono stati ampiamente accettati per aree di business specifiche, ad esempio transazioni commerciali.

L'altro motivo principale per adottare una soluzione molto chiusa è il supporto legacy. Uno dei prodotti che hai citato (Pervasive SQL) ha funzionato come una porta senza sforzo per le applicazioni basate su BTrieve alla fine degli anni '90, e ha guadagnato popolarità grazie all'enorme comunità BTrieve in tutto il pianeta.

Infine, ultimo ma non meno importante, dovresti valutare il TCO (costo totale di proprietà) non solo in termini di prezzo della licenza (sede singola, ambiente di rete, licenze del sito e così via), ma anche per quanto riguarda il supporto tecnico, aggiornamenti e disponibilità per la tua piattaforma. Molte unità aziendali che conosco sono state obbligate a modificare il loro sistema operativo di base per problemi relativi al DB.

Suggerimento: aggiungi un bonus per la soluzione personalizzata che è provata o supportata per l'utilizzo in ambienti virtualizzati, se non sei alla ricerca di prestazioni estreme. Salverà più di un mal di testa per il tuo gestore DB.

In tutti gli altri casi, fare affidamento su DB open source / freesoftware. MySql e Postgres per grandi progetti, SQLite per il livello di persistenza delle singole app. Supporto abbastanza standard e molto buono (di comunità). Buon valore senza prezzo.

Non ho alcuna esperienza con i prodotti di database proprietari che hai elencato: 4D, Pervasive, FilemakerPro.

Sarei interessato a sapere cosa offrono quei prodotti che li rendono più interessanti delle alternative open source, che hai elencato: MySQL e PostgreSQL.

Sarei interessato a ciò che li rende più interessanti delle alternative proprietarie molto più popolari: Oracle, SQL Server, DB2, ecc.

Senza che tu fornisca ulteriori dettagli, è difficile consigliarti.

Personalmente mi sento più sicuro utilizzando una soluzione open source ampiamente utilizzata rispetto a una soluzione chiusa di tipo strettamente usato. Più è ampiamente usato, più è probabile che sia testato in battaglia. Più aperto, più controllo ho sul mio destino nel caso in cui incontrassi qualche bug.

Ho segnalato dei bug a progetti open source e ho ottenuto una soluzione rapida. Ho segnalato bug a società che producono software proprietario a scopo di lucro e non hanno ottenuto nulla.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top