Перейти к содержанию
Fire Monkey от А до Я
  • 0

Работа с БД Firebird


d7d1cd

Вопрос

Привет всем! Есть база данных Firebird. Необходимо из приложения отправить SQL запрос для этой базы и полученные данные вывести в список ListBox. Подскажите, какие компоненты FireDAC необходимо использовать для этого.

Ссылка на комментарий

Рекомендуемые сообщения

  • 0

совет: не общайтесь с БД напрямую. черевато. нужно какая-то прослойка в виде какого-либо апп-сервера. удобно например через rest.

 

ну а если совсем уж нужно, почитайте вот здесь:

http://docwiki.embarcadero.com/RADStudio/XE7/en/FireDAC

Ссылка на комментарий
  • 0

совет: не общайтесь с БД напрямую. черевато. нужно какая-то прослойка в виде какого-либо апп-сервера. удобно например через rest.

 

 

ruslan, простите, но почему нельзя общаться с БД напрямую? Простите, если мой вопрос совсем как чайника! Это касается только БД Firebird или всех? И в каком случае? Мобильные? Просто первый раз такое слышу, поэтому и спрашиваю. Работаю с десктопами.

Ссылка на комментарий
  • 0
  • Модераторы

 

совет: не общайтесь с БД напрямую. черевато. нужно какая-то прослойка в виде какого-либо апп-сервера. удобно например через rest.

 

 

ruslan, простите, но почему нельзя общаться с БД напрямую? Простите, если мой вопрос совсем как чайника! Это касается только БД Firebird или всех? И в каком случае? Мобильные? Просто первый раз такое слышу, поэтому и спрашиваю. Работаю с десктопами.

 

1) это не безопасно, т.к. логин-пароль храните в приложении и большой риск что его могут достать

2) постоянный коннект с БД тоже плохо

3) клиента можно разгрузить и переложить часть операции на сервер

4) ответ о дисконнекте с базой трудно отловить, проще по HTTP (он точно вернет ошибку, даже если инет пропадёт)

Ссылка на комментарий
  • 0

все же от задачи зависит...

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

постоянный коннект с базой с толстого клиента по локалке ничем не хуже постоянного коннекта с ней HTTP-сервера и уж точно лучше чем 100500 переконнектов

логин-пароль я вообще ставлю один гостевой на вход в базу в процедуру аутентификации, а авторизацию я провожу сам. она идет уже после ввода пароля вручную, HTTP-сервер работает точно так же

часть операций выполняют хранимые процедуры на сервере

при активном использовании дисконнект проявится мгновенно

 

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

Ссылка на комментарий
  • 0

все же от задачи зависит...

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

постоянный коннект с базой с толстого клиента по локалке ничем не хуже постоянного коннекта с ней HTTP-сервера и уж точно лучше чем 100500 переконнектов

логин-пароль я вообще ставлю один гостевой на вход в базу в процедуру аутентификации, а авторизацию я провожу сам. она идет уже после ввода пароля вручную, HTTP-сервер работает точно так же

часть операций выполняют хранимые процедуры на сервере

при активном использовании дисконнект проявится мгновенно

 

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

Не согласен с вашими доводами. Надо учитывать транзакционную модель Interbase/Firebird.

Если у вас 2-5 клиентов - ваш вариант ещё может "прокатить". При больших нагрузках получите кучу deadlock'ов.

И вообще правильнее будет, что зависит не от задачи, а от архитектуры программы.. Если уже имеется трёхзвенка, то не надо ничего иного придумывать..

 

И если вернуться к начальному вопросу темы, то запрос к базе - это текстовая строка.. учитывая, что имеется сервер, то вопрос стоит в том, чтобы отправить текст запроса на этот сервер и получить в ответ результаты запроса.. думаю FireDAC к этому отношения не имеет..

для начала надо узнать как устроен сервер и в каком формате он выдаёт результаты запросов - после этого можно будет думать какими компонентами получать эти результаты запросов.

Ссылка на комментарий
  • 0

30~70 сигналов в секунду поступают в базу. Сервер обработки данных обрабатывает сырые исходные данные и кладет обратно в ту же базу. 10-30 клиентов смотрят визуализацию в "реальном времени" и заводят данные о событиях в системе. вполне себе нагрузка. С транзакциями все хорошо.

HTTP сервер для каждого запроса будет все равно изображать отдельного пользователя. Пусть даже с пулом коннектов. В чем выигрыш? 

При интенсивном обмене это очень замедлит передачу данных

"запрос к базе - это текстовая строка"

 

а вот ответ - совсем не факт. и чем более компактно он выглядит, тем выше скорость обмена.

так что именно от задачи выстраивается архитектура.

 

опять же, для 100+ клиентов делать 2 звена - это ставить базу на колени, так что сразу появится вынужденный промежуточный сервер. но таких задач мне не попадалось. Либо интенсивно и мало юзеров, либо много юзеров, но в нормальном неспешном режиме, а для этого есть php. Мы же не фейсбук пишем...

Ссылка на комментарий
  • 0

30~70 сигналов в секунду поступают в базу. Сервер обработки данных обрабатывает сырые исходные данные и кладет обратно в ту же базу. 10-30 клиентов смотрят визуализацию в "реальном времени" и заводят данные о событиях в системе. вполне себе нагрузка. С транзакциями все хорошо.

HTTP сервер для каждого запроса будет все равно изображать отдельного пользователя. Пусть даже с пулом коннектов. В чем выигрыш? 

При интенсивном обмене это очень замедлит передачу данных

В режиме HTTP-сервера можно, например, сжать данные для уменьшения трафика, убрать весь доп.служебный трафик от СУБД.

 

"запрос к базе - это текстовая строка"

 

а вот ответ - совсем не факт. и чем более компактно он выглядит, тем выше скорость обмена.

так что именно от задачи выстраивается архитектура.

 

вы не поверите, но именно про архитектуру я и говорил в своём сообщении )) у вас же наоборот совет напрямую клиентом к БД подключаться..

 

 

опять же, для 100+ клиентов делать 2 звена - это ставить базу на колени, так что сразу появится вынужденный промежуточный сервер. но таких задач мне не попадалось. Либо интенсивно и мало юзеров, либо много юзеров, но в нормальном неспешном режиме, а для этого есть php. Мы же не фейсбук пишем...

для примера - я в билайне на поддержке биллинговой системы работал.. там базы 18 ТБ.. очень интересно было посмотреть как всё устроено...

 

а из того, что лично было сделано -  приложение с 20-30 клиентами на планшетах.. используется HTTP-сервер для получения информации из БД.. одной из задач является отображение списка с фотографиями из 200-1000 элементов.. объём передаваемых данных при этом измеряется порядка 20-30 МБ на каждого клиента при открытии сессии.. после написания "прямого" вариант фактическая скорость загрузки оказалась чрезвычайно низкой.. и одним из узких мест было чтение картинок (blob-полей) из БД.. для решения этой проблемы был создан кэш картинок на стороне сервера и картинки брались не из БД, а из этого кэша - скорость загрузки картинок на планшет удалось поднять в несколько раз..

 

Так что не всегда двухзвенка имеет преимущества даже на малом количестве клиентов..

Ссылка на комментарий
  • 0

1) это не безопасно, т.к. логин-пароль храните в приложении и большой риск что его могут достать

 

 

2) постоянный коннект с БД тоже плохо

3) клиента можно разгрузить и переложить часть операции на сервер

4) ответ о дисконнекте с базой трудно отловить, проще по HTTP (он точно вернет ошибку, даже если инет пропадёт)

 

обана опять холивары про клиент сервер ? )))

1) у меня логины в систему и есть логины в MSSQL, пароль не храниться НИГДЕ кроме как в бд, а безопасность разделяется ролями в БД, а это наивысшая безопасность к данным, которые храняться в БД, если руки не кривые.

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

3) вы хотите сказать переложить операции на сервер ВАШ, но никак не БД ! А вот в клиент-сервере на 100% на сервер БД, если хранимые процедуры используются.

Ссылка на комментарий
  • 0

опять же, для 100+ клиентов делать 2 звена - это ставить базу на колени,

не понял, какой сервер? MSSQL 100000 сессий это так пощекотать...а ORACLE даже не заметит...

опять таки вы про сессии? или реализацию? на 3х звенке на колени легко, т.к. там редко пишут на хранимых, в основном SQL...и часто чхать хотели на безопасность по логинам и и ролям в БД.

Ссылка на комментарий
  • 0

Мы же не фейсбук пишем...

а вот тут согласен на 300%, многие прогеры плевать хотели на сроки реализации программы, и бьют пушками по воробьям, очень многим невдомек, что если вас стали досить, то это достижение высокого уважения и пора бежать за пивом...а иначе самолюбие говнокодера не дает покоя...и как результат "прогер" окончательно забывает как переводиться слово RAD, и ему требуется десятки раз надо бить по лбу переводом, скажу больше 3х звенку на делфях не очень то профессионально делать...т.к. это ПРОТИВОРЕЧИТ  переводу RAD. 3-х звенка вещь профессиональная, и на ней нужен C# господа, да да, т.к. никакой это нафиг не RAD. С# вот понимаю, дофига времени, резиновый срок, и т.п., и кстати весьма профессиональное приложение на выходе, а не приколы с атомами, группа пуш, видео-как фото, и т.п. косяки абсолютно не приемлемые в профи-прогах )). 

Ценовая политика RAD явно не претендует на экспансию в развитые страны, а в основном в 3-и мира...собственно где мы и находимся )). Так что клиент-сервер самое то, срубить бабло и был таков...)

Ссылка на комментарий
  • 0

для примера - я в билайне на поддержке биллинговой системы работал.. там базы 18 ТБ.. очень интересно было посмотреть как всё устроено...

не понял, какой пример? вы хоть что то бы описали...о чем вообще хотели рассказать? я тоже 5 лет! (дикий срок...) проработал в GSM компании, там 20млрд транзакций в день, оракл,  и что?? там то я и увидел что такое 3-х звенка и как ее делают Java кодеры ). Никаких хранимок, "динамичный sql" и т.п. и как результат, сделали из оракл - foxpro...а стоимость то оракл...да это как бентли юзать, чтобы овец перевозить...

Ссылка на комментарий
  • 0

 и одним из узких мест было чтение картинок (blob-полей) из БД.. для решения этой проблемы был создан кэш картинок на стороне сервера и картинки брались не из БД, а из этого кэша - скорость загрузки картинок на планшет удалось поднять в несколько раз..

да походу вы просто не разобрались в чем проблема...вы организовали хранение картинок как файлы или что-то подобное...а на самом деле, узкое место было как раз ваша 3-х звенка...т.к. по вашему примеру вижу неважный трафик между вашим сервером и сервером БД...

сам я храню в БД картинки, да в блобах, но качаю разово на клиента все картинки для imagelist до изменения. Дизайнеру картбланш на все иконки в программе, и он все правит, меня не беспокоя...

Ссылка на комментарий
  • 0

 

не понял, какой пример? вы хоть что то бы описали...о чем вообще хотели рассказать? я тоже 5 лет! (дикий срок...) проработал в GSM компании, там 20млрд транзакций в день, оракл,  и что?? там то я и увидел что такое 3-х звенка и как ее делают Java кодеры ). Никаких хранимок, "динамичный sql" и т.п. и как результат, сделали из оракл - foxpro...а стоимость то оракл...да это как бентли юзать, чтобы овец перевозить...

Кем вы работали в GSM-компании если не секрет? И в какой GSM-компании работали?

Что там оракл и как устроена вся система я успел рассмотреть.. рассказывать о том, как устроена их система - это не вопрос двух-трёх слов.. поэтому я и не думал даже какие-то детали оттуда приводить..

 

Про трёхзвенку на C# - это высший пилотаж! )) можно мне трёхзвенку на C# под линукс и солярис?

 

 

да походу вы просто не разобрались в чем проблема...вы организовали хранение картинок как файлы или что-то подобное...а на самом деле, узкое место было как раз ваша 3-х звенка...т.к. по вашему примеру вижу неважный трафик между вашим сервером и сервером БД...

 

сам я храню в БД картинки, да в блобах, но качаю разово на клиента все картинки для imagelist до изменения. Дизайнеру картбланш на все иконки в программе, и он все правит, меня не беспокоя...

 

картинки как раз в блобах и лежат.. а выводы были сделаны после сравнения производительности SQL-запроса с выборкой из блобов и без них.. можно было бы закачать все картинки разом если бы их не было примерно так тыс 15-20 и число их постоянно растёт, а на планшете "здесь и сейчас" нужны только часть из имеющихся картинок.. картинки в данном случае - это jpeg-файлы размером 40-150 кб.. как думаете сколько времени бы программа тратила на закачку такого объёма картинок?

Да, ещё такой момент - картинки на планшете нельзя сохранять.. Требования от службы безопасности.. а обновление списка фотографий идёт в режиме реального времени от нескольких штук до десятков штук в минуту..

 

P.S. и наверное я за 18 лет программирования, больше 10 лет работы с Firebird'ом и нескольких реализованных проектов совершенно не понимаю чего я делаю ) Следующий раз обязательно буду у вас спрашивать как мне лучше организовать архитектуру своих проектов )

Изменено пользователем Nik
Ссылка на комментарий
  • 0

.. можно было бы закачать все картинки разом если бы их не было примерно так тыс 15-20 и число их постоянно растёт, а на планшете "здесь и сейчас" нужны только часть из имеющихся картинок.. картинки в данном случае - это jpeg-файлы размером 40-150 кб.. как думаете сколько времени бы программа тратила на закачку такого объёма картинок?

вы точно знаете для чего нужен SQL? Вот foxpro как раз вашу задачу и решает...таблица дает все что хотите...но именно все, а не часть )

 

P.S. и наверное я за 18 лет программирования, больше 10 лет работы с Firebird'ом и нескольких реализованных проектов совершенно не понимаю чего я делаю ) Следующий раз обязательно буду у вас спрашивать как мне лучше организовать архитектуру своих проектов )

за 10 лет работы ни разу не наткнулись на недостатки что описал выше?...это что за проекты такие...они точно дают прибыль?

 

Кем вы работали в GSM-компании если не секрет? И в какой GSM-компании работали?

не задавайте бестактные вопросы, если хотите ответа ), может и размер ЗП (зарплаты) сообщить? Ладно подскажу компания KC...L

был чуть ли не профи прогером по pl/sql. Позже я возненавидел оракл, т.к. познал какая отвратительная работа по администрированию его.

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

Сейчас больше нравиться MSSQL, там чувствуют комфортно обе стороны, прогеры и админы.

На текущий момент прибыль дает больше VCL чем FMX...но я стараюсь сравнять неравенство, т.к. полюбил облака, ведь это свобода.

 

P.S.: годы когда сидел на ЗП(без этого опыта не будет) я стараюсь не вспоминать, ведь сидеть на зарплате это верх ужаса что могло человечество придумать...

сидеть с 9 - 18:00, клянчить отлучки по личным делам, срок отпуска курам на смех(у меня собака и то свободнее).

Ссылка на комментарий
  • 0

вы точно знаете для чего нужен SQL? Вот foxpro как раз вашу задачу и решает...таблица дает все что хотите...но именно все, а не часть )

Если вы не заметили, то я говорил только про загрузку картинок через кэш. Всю остальную работу предпочитаю делать через хранимки. В том числе, получать отчёты сразу готовыми - остаётся только отформатировать вывод.

 

Про проекты - много проектов было (информация нашла адресата и подлежит удалению :) )

 

По поводу работы спросил - не заметил, что в Казахстане проживаете - было интересно узнать какое ПО другие операторы используют в работе.

 

Про оракл в чём-то согласен с вами, но есть там и очень вкусные плюшки в SQL.. сейчас Firebird начинает подтягиваться в этом к ораклу.. А вот MS SQL меня не особо впечатлил - хотя свои плюшки тоже имеются - отчёты удобно в нём делать..

Изменено пользователем Nik
Ссылка на комментарий
  • 0

А автор сабжа просто спросил какие компоненты использовать для коннекта к БД )))

FDConnection, FDQuery, FDTransaction - при необходимости, ну и FDPhysFBDriverLink и кинь ещё FDGUIWaitCursor

Ссылка на комментарий
  • 0

А автор сабжа просто спросил какие компоненты использовать для коннекта к БД )))

FDConnection, FDQuery, FDTransaction - при необходимости, ну и FDPhysFBDriverLink и кинь ещё FDGUIWaitCursor

С первой строчкой согласен ) со второй нет - там ниже указано, что имеется сервер промежуточный и данные компоненты не подойдут для решения задачи..

Но смешное в этой "истории" другое - судя по всему данную тему вернул в обсуждение бот рекламный )

Изменено пользователем Nik
Ссылка на комментарий
  • 0

А автор сабжа просто спросил какие компоненты использовать для коннекта к БД )))

FDConnection, FDQuery, FDTransaction - при необходимости, ну и FDPhysFBDriverLink и кинь ещё FDGUIWaitCursor

Спасибо тебе, добрый человек!

 

С первой строчкой согласен ) со второй нет - там ниже указано, что имеется сервер промежуточный и данные компоненты не подойдут для решения задачи..

 

Либо я чего-то не понимаю, либо читающие. Когда я писал про сервер, то это означало, что на компьютере с базой данных установлена программа, которая запускалась как сервис. Эта программа и работала непосредственно с файлом базы данных. Компьютер с этой программой и файлом базы данных и есть сервер. Почитайте тут https://ru.wikipedia.org/wiki/Firebird

 

Вопрос всем: уважаемые, кто-нибудь из вас работал с базой данных Firebird? Не с какой-то другой, а именно с этой базой данных?

Изменено пользователем d7d1cd
Ссылка на комментарий
  • 0

Компьютер с этой программой и файлом базы данных и есть сервер. Почитайте тут https://ru.wikipedia.org/wiki/Firebird

зачем вы на вики отправляете...если вы не отличаете термины СУБД и БД...размечтались работать с файлом напрямую ))

Ссылка на комментарий
  • 0

Вопрос всем: уважаемые, кто-нибудь из вас работал с базой данных Firebird? Не с какой-то другой, а именно с этой базой данных?

 

 

Не поверите, но именно с Firebird я и работаю в основном во всех своих проектах ))

 

И если Andy правильно понял ваши объяснения (как оказывается), то он вам верно ответил.

А про терминологию rustam_d верно подметил ))

Ссылка на комментарий

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить на вопрос...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...