la connettività di database Delphi

Question

Sto usando Delphi per anni, ma mai per le cose di base di dati, ma recentemente iniziato la ricerca e la sperimentazione.

Devo dire, sono impressionato, la maggior parte delle cose avviene automaticamente, io sono abituato a scrivere a mano in PHP e Python.

ho intenzione di sviluppare un sistema commerciale per un amico, (2 strati) computer 5 utenti, 1 server di database.

server di database sarà una macchina decente con 2 hard disk (RAID-1) in esecuzione (o MySql5.1 Postgre o Firebird, aperto a suggerimenti).

ADO

• Facile da usare
• Facile implementazione (solo installatore mysqlconnector)
• Il più lento?

DbExpress

• Hai bisogno di spedire 4 file [dbxconnections.ini, dbxdrivers.ini, mysqldll, driverdll]
• Il più complessa (più difficile da usare)
• ClientDataSet aggiungere complessità, ma sembra davvero utile
• Nessun driver libero Postgre?

Zeos

• Facile implementazione (1 dll)
• Facile da usare

Come si può vedere le caratteristiche desiderate sono:

• veloce
• facile da usare
• facile da implementare

Non riesco a testare il tutto in uno scenario reale (client, server), quindi spero che voi ragazzi con esperienza mi può aiutare in quale scegliere e perché.

EDIT: Grazie a tutti, penso che andrò con ADO (probabilmente) o Zeos

Grazie in anticipo
Arthur

Answer 1

Ho lavorato su molti sistemi ad alto volume commerciali che utilizzano ADO senza problemi. La distribuzione è relativamente semplice in quanto la sua incluso nel sistema operativo. Dal momento che ha un vasto pubblico, quali, la maggior parte dei problemi principali sono stati identificati e corretti. Ottenere aiuto con connettività ADO è molto facile. Il supporto del database è molto profondo ( connectionstrings.com ) che rendono di supporto motori di database aggiuntivi quasi banale (potrebbe essere necessario ancora installare i driver client, ma che sarebbe lo stesso per quasi ogni soluzione).

Le prestazioni non è molto più di un problema, in realtà scenderà a architettura del database e la selezione del motore.

Answer 2

@arthurprs, per lo scenario

  

(2 strati) 5 computer degli utenti, 1> server di database.

alt text http://www.techsolusa.com/images/firebird -Logo-64.gif Il Firebird RDBMS è una buona opzione, perché è molto stabile , veloce, gira su Linux, Windows, e una varietà di piattaforme Unix e incontrarsi con voi requisiti.

alt text http://d.yimg.com /kq/groups/12858579/homepage/name/homepage.jpg Rispetto ai componenti per il collegamento vado per ZEOS .

Ho usato questa combinazione in molti progetti di piccole e medie, con ottimi risultati.

Answer 3

id hanno da dire im piuttosto felice con NexusDB ma il costo per le versioni client / server potrebbe non valerne la pena.

funziona client / server o completamente integrato, abbastanza semplice si può avere sia nella vostra app e passare da uno all'altro, a seconda delle esigenze dei clienti

• DB incorporato è libera,
• client / server "Prezzo speciale per sviluppatore" è AU $ 500
• Nessun costo per l'installazione.

Oh yeh e il suo scritto in Delphi;)

Answer 4

Direi di andare con Firebird - è il motore di database più usato nella terra Delphi (vedi qui ). Per la connettività forse è meglio andare con Zeos (gratuito) o DBX (se lo può permettere la versione Architect - l'unico che ha il driver Firebird in esso).

A proposito di ADO: maturo livello di connettività, ma sarà (per sempre - più probabilmente) legato a Windows mentre Delphi andrà cross-platform. Inoltre, sì, tendono ad essere la più lenta a causa di vari motivi, tra cui i driver ODBC che vengono utilizzati in determinate situazioni. Ma nel tuo caso, naturalmente, come skamradt dice, non lo faccio pensare che importa così tanto.

Answer 5

Anche se ho letto la gente non gradire l'idea di mescolare i due, ho avuto buoni risultati utilizzando ADO set di dati come un "livello di provider", che poi alimenta i dati in TClientDataSets - quindi non c'è ragione per cui non è possibile utilizzare ClientDataSets se si scende il percorso ADO se si trova ne avete bisogno (e sono utili).

In caso contrario, mi associo al commento che ADO è un provato, meccanismo di fiducia che non sta andando da nessuna parte. Ho sempre trovato più che abbastanza veloce. E configurazione utilizzando i file UDL è bello e facile.

Answer 6

• dbGo (ADO) è più semplice da gestire, più universale, più lento
• dbExpress è più veloce, più complesso da gestire, supporta meno DBMS
• ZeosDBO è semplice da gestire, universale come dbExp, lento come dbGo, cross-platform, ha pochi componenti aggiuntivi, tutte le fonti sono accessibili

Ci sono poche altre librerie, risolvendo tutti i dubbi di cui sopra, anche se tutti sono prodotti commerciali. Ma ci sono di parte:)

Answer 7

Abbiamo usato PostgreSQL usando componenti Devart pg con grande successo in applicazioni di database di medie dimensioni. Abbiamo fatto qualche analisi comparativa limitata con questa combinazione e l'ho trovato 2-3 x la velocità di utilizzo di ADO etc.

Answer 8

- Data Access Components

Anche Io sono a favore della combinazione di TClientDataset e ADO. Aveva lavorato con lui in passato e posso dire che è fiduciosa. La flessibilità di TClientDataset è un grande guadagno. DBExpress è troppo buono. In realtà, io uso clientdatasets con praticamente qualsiasi livello di accesso ai dati che hanno un discendente TDataset ...

- Server

Firebird. Gratuito e facilmente utilizzabile da OLE DB (ho usato con ODBC) e DBExpress (D2010 + avere driver nativo DBX) - non so ZEOS, ma credo che si collega anche a FB. Scala bene a molti collegamenti e grandi basi di dati. Ci sono banche dati su Firebird con 500Gb e molti utenti hanno segnalato.