Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 SQL для рабочей станции.  [new]
Underking
Member

Откуда: Rostov-on-Don
Сообщений: 488
Есть программа, которая ставится на обычный комп, не в сети. Этой программе требудется хранить достаточно большие объемы с не самой простой структурой.
Трубуется SQL, который будет занимать мало места, не будет требовать установки и регистрации на этом компьютере, т.е. переписали несколько файликов на компьютер и все.
При этом кране желательно работать с этой базой в Delphi через ADO компоненты.
2 июн 06, 15:41    [2735451]     Ответить | Цитировать Сообщить модератору
 Re: SQL для рабочей станции.  [new]
Syleiman
Member

Откуда:
Сообщений: 41
Попробуй Firebird.
Он, правда, из дистрибутива ставится.
2 июн 06, 16:09    [2735733]     Ответить | Цитировать Сообщить модератору
 Re: SQL для рабочей станции.  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290

Sybase SQL Anywhere

Underking пишет:
> программе требудется хранить достаточно большие объемы с не самой
> простой структурой.

Запросто.

> Трубуется SQL, который будет занимать мало места, не будет требовать
> установки и регистрации на этом компьютере, т.е. переписали несколько
> файликов на компьютер и все.

Около 3 мб в архиве - все что надо, чтобы получить полноценный сервер БД.

> При этом кране желательно работать с этой базой в Delphi через ADO
> компоненты.

Полагаю, сейчас сложно найти сервер, к которому нет возможности
достучаться через ADO

Posted via ActualForum NNTP Server 1.3

2 июн 06, 16:15    [2735786]     Ответить | Цитировать Сообщить модератору
 Re: SQL для рабочей станции.  [new]
Underking
Member

Откуда: Rostov-on-Don
Сообщений: 488
Последние 4 дня я пытаюсь добиться нормальной работы с Firebird.
Но вот добиться с ней работы через ADO не получается.
До этого работали с MSSQL и выработали целую стратегию построения хранимых процедур на сервере и работы с ними из Delphi. Но к сожалению с Firebird это сделать не удалось.

автор
Sybase SQL Anywhere

Там есть процедуры, в которых я могу передавать параметры, делать Insert, Update, Delete, а также делать SELECT, который вернет мне recordset?
2 июн 06, 16:37    [2736016]     Ответить | Цитировать Сообщить модератору
 Re: SQL для рабочей станции.  [new]
hvlad
Guest
Underking
Последние 4 дня я пытаюсь добиться нормальной работы с Firebird.
Но вот добиться с ней работы через ADO не получается.
До этого работали с MSSQL и выработали целую стратегию построения хранимых процедур на сервере и работы с ними из Delphi. Но к сожалению с Firebird это сделать не удалось.
Не стоит позориться ещё и здесь...
2 июн 06, 16:47    [2736104]     Ответить | Цитировать Сообщить модератору
 Re: SQL для рабочей станции.  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290

Underking пишет:

> Последние 4 дня я пытаюсь добиться нормальной работы с Firebird.
> Но вот добиться с ней работы через ADO не получается.

Не будучи спецом по FB, с ходу могу предложить ссылку:
http://ibase.ru/components.htm
Если этого недостаточно, то что-то не так в консерватории.

>> Sybase SQL Anywhere
> Там есть процедуры, в которых я могу передавать параметры, делать
> Insert, Update, Delete, а также делать SELECT, который вернет мне recordset?

А где этого нет?

Posted via ActualForum NNTP Server 1.3

2 июн 06, 17:05    [2736221]     Ответить | Цитировать Сообщить модератору
 Re: SQL для рабочей станции.  [new]
Underking
Member

Откуда: Rostov-on-Don
Сообщений: 488
С Fireberd проблемка есть, не все там так гладко. В соответствующем форуме уже на меня вон смотрят косо, даже hvlad и здесь высказался. Хотя весь прикол в том, что работая с Faerbird можно не догадываться, что существуют сервера куда как лучше, и следовательно непонимать проблемы человека, пересевшего с мерса на жигули. :)

В часности для получения из поцедуры селекта в виде dataset там приходится в самом клиенте писать
IBQuery.SQL = 'select *from MyProc'
в то время как в связке ADO + MSSQL есть простой метод
ADOStoredProc.ProcName = 'MyProc'
2 июн 06, 17:32    [2736453]     Ответить | Цитировать Сообщить модератору
 Re: SQL для рабочей станции.  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290

Underking пишет:

> С Fireberd проблемка есть, не все там так гладко.

Гладких серверов не бывает.

> В соответствующем форуме уже на меня вон смотрят косо, даже hvlad
> и здесь высказался.

Предположу, что есть за что. По крайней мере с его точки зрения.

> Хотя
> весь прикол в том, что работая с Faerbird можно не догадываться, что
> существуют сервера куда как лучше,

А это прикол не Firebird, а конкретных людей. Что мешает оглянуться
вокруг и присмотреться?

> В часности для получения из поцедуры селекта в виде dataset там
> приходится в самом клиенте писать
>
> IBQuery.SQL = 'select *from MyProc'

А что в этом плохого? Универсальный, удобный и простой способ. Что
select, что вызов процедуры - все это с точки зрения клиента просто
тексты запросов, посылаемых на сервер.

> в то время как в связке ADO + MSSQL есть простой метод
>
> ADOStoredProc.ProcName = 'MyProc'

Это и есть главная причина недовольства?

Posted via ActualForum NNTP Server 1.3

2 июн 06, 18:32    [2736854]     Ответить | Цитировать Сообщить модератору
 Re: SQL для рабочей станции.  [new]
Underking
Member

Откуда: Rostov-on-Don
Сообщений: 488
автор
> IBQuery.SQL = 'select *from MyProc'

А что в этом плохого? Универсальный, удобный и простой способ. Что
select, что вызов процедуры - все это с точки зрения клиента просто
тексты запросов, посылаемых на сервер.

Клиента пишет один человек, процедурами на сервере занимается другой. Причем друг друга заменить они не могут. Теперь относительно универсальную процедуру решили использовать еще для одной задачи, добавив всего один параметр.
В случае если клиент выполняет запросы ADOStoredProc.Open, перед этим прочитав параметры и заполнив только необходимые, с ним ничего делать не надо, программист не исравляет клиента, не перекомпилирует, не переписывает всем пользователям.
У меня для базы на MSSQL есть формы, которыми пользуются уже который год, не трогая их. В то время как в саму процедуру, используемую ими, уже столько изменений внесли.

Да, сразу отвечаю на вопрос, почему бы для другой задачи не использовать другой запрос. Так появится третий, четвертый, пятый и т.д. А потом потребуется во всех этих процедурах поменять алгоритм расчета. А вот при использовании моей стратегии, вся замена делается в одной процедуре.

Будет ли эта процедура тормозить?
Ну тут если грамотно делать, и в разумных пределах, то все будет очень хорошо работать. Проверяно на достаточно большой базе, которую дерут 24 часа в сутки, 7 дней в неделю, ну может ночью менее интенсивно.

автор
Это и есть главная причина недовольства?

Да, создатель клиента не хочет (и этого не нужно) синхронизировать свою работу с моей. И он не SQL программист.
2 июн 06, 19:13    [2737013]     Ответить | Цитировать Сообщить модератору
 Re: SQL для рабочей станции.  [new]
Sergey Ch
Member

Откуда: Благовещенск
Сообщений: 8894
Underking
Есть программа, которая ставится на обычный комп, не в сети. Этой программе требудется хранить достаточно большие объемы с не самой простой структурой.
Трубуется SQL, который будет занимать мало места, не будет требовать установки и регистрации на этом компьютере, т.е. переписали несколько файликов на компьютер и все.
При этом кране желательно работать с этой базой в Delphi через ADO компоненты.

MS VFP OLE DB provider 9.1 ...
2 июн 06, 19:53    [2737075]     Ответить | Цитировать Сообщить модератору
 Re: SQL для рабочей станции.  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290

Underking пишет:

> Клиента пишет один человек, процедурами на сервере занимается другой.
> Причем друг друга заменить они не могут. Теперь относительно
> универсальную процедуру решили использовать еще для одной задачи,
> добавив всего один параметр.

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

>> Это и есть главная причина недовольства?
> Да, создатель клиента не хочет (и этого не нужно) синхронизировать свою

Ну, если такая задача стала непреодолимым препятствием, тогда стоит
подумать о смене рода деятельности.

Posted via ActualForum NNTP Server 1.3

2 июн 06, 19:55    [2737080]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить