Delphi возможности соединения базы данных

Я использую Дельфи в течение многих лет, но никогда для материала базы данных, но недавно начал исследовать и тестировать.

Я должен сказать, я впечатлен, большинство вещей происходит автоматически, я используюсь для записи вручную в php и Python.

я собираюсь разработать коммерческую систему для друга, (2 слоя) 5 компьютеров пользователей, 1 сервер базы данных.

Сервер базы данных будет достойной машиной с (совершите рейд 1), 2 выполнения жестких дисков (MySql5.1 или Postgre или Firebird, открытый для предложений).

ADO

  • Простой в использовании
  • Простое развертывание (только mysqlconnector установщик)
  • Медленнее?

DbExpress

  • Должен поставить 4 файла [dbxconnections.ini, dbxdrivers.ini, mysqldll, driverdll]
  • Более сложное (тяжелее для использования)
  • ClientDataSet добавляют сложность, но выглядит действительно полезным
  • Никакой свободный драйвер Postgre?

Zeos

  • Простое развертывание (1 dll)
  • Простой в использовании

Поскольку Вы видите, что желаемые функции:

  • быстро
  • простой в использовании
  • легкий развернуться

Я не могу протестировать все в реальном сценарии (клиенты, сервер), таким образом, я надеюсь, что парни с опытом можно выручить меня в который выбрать и почему.

Править: Спасибо все, я думаю, что пойду с ADO (вероятно), или Zeos

Заранее спасибо
Arthur

7
задан arthurprs 18 February 2010 в 14:18
поделиться

8 ответов

Я без проблем работал со многими коммерческими крупносерийными системами с использованием ADO. Развертывание относительно простое, поскольку оно включено в ОС. Поскольку у него такая широкая аудитория, большинство основных проблем были выявлены и исправлены. Получить справку по подключению ADO очень просто. Поддержка базы данных очень обширна ( connectionstrings.com ), что делает поддержку дополнительных механизмов базы данных почти тривиальной (возможно, вам все равно придется установить клиентские драйверы, но это будет одинаково практически для любого решения).

Производительность не является большой проблемой, она действительно сводится к архитектуре базы данных и выбору движка.

4
ответ дан 6 December 2019 в 19:36
поделиться

@arthurprs, для вас сценарий

(2 уровня) 5 пользовательских компьютеров, 1> сервер базы данных.

alt text http://www.techsolusa.com/images/firebird-logo-64.gif СУБД Firebird - очень хороший вариант, потому что она очень стабильна, быстра, работает на Linux, Windows и различных платформах Unix и удовлетворить ваши требования.

альтернативный текст http://d.yimg.com/kq/groups/12858579/homepage/name/homepage.jpg Уважение к компонентам для подключения Я выбираю ZEOS .

Я использовал эту комбинацию во многих малых и средних проектах с отличными результатами.

5
ответ дан 6 December 2019 в 19:36
поделиться

Я должен сказать, что я довольно доволен NexusDB , но стоимость версий клиент / сервер может не окупиться.

он работает клиент / сервер или полностью встраивается, достаточно просто, вы можете иметь и то, и другое в своем приложении и переключаться между ними, в зависимости от потребностей ваших клиентов

О да, и он написан на delphi;)

2
ответ дан 6 December 2019 в 19:36
поделиться

Я бы посоветовал выбрать Firebird - это наиболее используемый движок баз данных в Delphi (см. здесь). Для подключения, возможно, лучше использовать Zeos (бесплатный) или DBX (если вы можете позволить себе версию Architect - единственную, в которой есть драйвер Firebird).

Насчет ADO: зрелый уровень связности, но он будет (навсегда - скорее всего) привязан к Windows, в то время как Delphi будет кроссплатформенным. Также, да, он имеет тенденцию быть более медленным из-за многих причин, включая драйверы ODBC, которые используются в определенных ситуациях. Но в вашем случае, конечно, как говорит skamradt, я не думаю, что это будет иметь такое большое значение.

1
ответ дан 6 December 2019 в 19:36
поделиться

Хотя я читал, что людям не нравится идея смешивать эти два, у меня были хорошие результаты, используя наборы данных ADO в качестве "уровня поставщика", который затем скармливает data в TClientDataSets - поэтому нет причин, по которым вы не можете использовать ClientDataSets, если вы идете по маршруту ADO, если вы обнаружите, что они вам нужны (и они полезны).

В противном случае я бы повторил комментарий, что ADO - это проверенный и надежный механизм, который никуда не денется. Я всегда находил это более чем достаточно быстро. А настройка с использованием файлов UDL проста и удобна.

1
ответ дан 6 December 2019 в 19:36
поделиться
  • dbGo (ADO) более прост в управлении, более универсален, более медленный
  • dbExpress более быстрый, более сложный в управлении, поддерживает меньше СУБД
  • ZeosDBO прост в управлении, универсален как dbExp, медленный как dbGo, кроссплатформенный, имеет мало дополнительных компонентов, все исходники доступны

Есть еще несколько библиотек, разрешающих все вышеперечисленные сомнения, хотя все они являются коммерческими продуктами. Но тут я необъективен :)

0
ответ дан 6 December 2019 в 19:36
поделиться

Мы с большим успехом использовали postgreSQL с компонентами Devart pg в приложениях баз данных среднего размера. Мы провели ограниченное тестирование этой комбинации и обнаружили, что она в 2–3 раза выше скорости использования ADO и т. Д.

0
ответ дан 6 December 2019 в 19:36
поделиться

- Компоненты доступа к данным

Я тоже предпочитаю комбинацию TClientDataset и ADO. Работал с этим в прошлом, и я могу сказать, что это надежно. Гибкость TClientDataset - большое преимущество. DBExpress тоже хорош. На самом деле, я использую клиентские наборы данных практически с любым уровнем доступа к данным, у которого есть потомок TDataset ...

- Сервер

Firebird. Бесплатно и легко используется из OLEDB (я использовал с ODBC) и DBExpress (D2010 + имеет собственный драйвер DBX) - не знаю ZEOS, но я считаю, что он также подключается к FB. Хорошо масштабируется для многих подключений и больших базы данных. На Firebird есть базы данных с 500 ГБ, и многие пользователи сообщили.

0
ответ дан 6 December 2019 в 19:36
поделиться
Другие вопросы по тегам:

Похожие вопросы: