ADO, FireDAC Создание структуры для запроса

@Dinkin · Регистрация: 31.05.2013

Студворк — интернет-сервис помощи студентам

Доброго!
Узнал что в FireDac (а скорее всего так же и в ADO) можно создавать структуры запроса, что ускоряет обмен данными,а так же позволяет работать с разными типами БД, не изменяя запроса.

Типа было

SQL
1
SELECT * FROM users WHERE  name = AAA

А стало (примерно так, точно не знаю)

SQL
1
SELECT * [tip1] WHERE  [tip2]  = [tip3]

Ни кто не использовал, может кто знает как с таким работать?

@Grossmeister · 26.04.2016, 16:05

Сообщение от Dinkin

можно создавать структуры запроса, что ускоряет обмен данными

О каком обмене данными идет речь? Клиентская программа посылает на сервер запрос, сервер этот запрос выполняет и возвращает результат на клиента. Этот результат и есть обмен данными, но от текста запроса это никак не зависит.
В нормальных СУБД есть оптимизатор, который составляет план запроса. Если запрос работает медленнее, чем требуется, то можно попытаться изменить текст запроса. Это называется оптимизация запроса, но в общем случае штука непростая и всяко не решается какими-то скобочками. Там требуется изучение плана запроса, который строит оптимизатор, понимание принципов работы конкретной СУБД и проч. Это может влиять на скорость выполнения запроса, но не на обмен данными (передачу данных по сети).
Ну и конечно на скорость выполнения запроса влияет структура БД, но это уже другая история.

@Dinkin · 26.04.2016, 16:22 **[ТС]**

Grossmeister, Спасибо за раскрытый ответ.

Под обменом данными я имел введу посылка самого запроса на сервер (Компонент TQuery его оптимизирует как то в независимо с какой БД работаем, он сам как надо сделает структуру запроса), а то есть :
1) К примеру есть запрос мего длинный, со всякими там джойнами и внутренними выборками, а TQuery, его оптимизирует и шлет на сервер
2) Другим плюсом является что в самом клиенте мы подставляем только сами переменные к уже готовому запросу, что уменьшает длину самого написания кода.
3) Главный плюс, что не важно с каким типом БД мы работаем, не надо подгонять запросы с MySQL к примеру на MSSQL,достаточно просто сменить провайдера,а TQuery сама уже преобразует запросы.

Как пример могу привести Entity Framework.

Добавлено через 3 минуты
Хотел добавить, что как то встречал в Блоге разработчика FireDac, примеры данной реализации, с замерами. Но к сожалению не придал тогда этому значения, а сейчас даже и блога этого найти не могу.

@Grossmeister · 26.04.2016, 17:03

Сообщение от Dinkin

1) К примеру есть запрос мего длинный, со всякими там джойнами и внутренними выборками, а TQuery, его оптимизирует и шлет на сервер

Это слишком интеллектуально для компонента. Расскажу на примере Oracle, поскольку знаю его лучше всего.

Во-первых, в СУБД оптимизатор оптимизируют

годами, если не десятилетиями. Т.е. это задача довольно сложная и отнюдь не для одного человека. И даже сейчас в том же Oracle оптимизатор порой ошибается.
Во-вторых, если какой-то запрос выполняется быстро на одной СУБД, не факт, что он будет работать быстро на другой. Поэтому невозможно оптимизировать запрос для разных СУБД, для этого надо знать ее особенности, иногда внутреннюю кухню, которую знают только в фирме-вендоре.
В-третьих, порой для оптимизации запроса надо иметь сведения о данных, насколько они распределены равномерно или нет. Для этого в СУБД существует сбор статистики по таблицам и индексам. И оптимизатор, составляя план запроса, использует эту статистику, т.е. сам выполняет запросы к БД (т.н. рекурсивные запросы).

@Dinkin · 26.04.2016, 17:13 **[ТС]**

Grossmeister, Oracle это ваще страшилки, дело не имел с ним, но заочно им уже запугали

А по вопросу темы, в общем пока сам толком не знаю, типа "слышал звон....", но точно знаю что есть возможность хотя бы в простых запросах как то сделать универсальную форму, что бы хотя бы подходила и к MsSQL , так и для MySQl для FireDac

.

@Grossmeister · 26.04.2016, 17:17

Сообщение от Dinkin

Oracle это ваще страшилки

Это не страшилки, это просто высокопрофессиональный инструмент. При достаточном умении много чего позволяет сделать.

Новые блоги и статьи Все статьи Все блоги /
сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/	WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .	Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .	Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .
Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114	Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .	Модель микоризы: классовый агентный подход 2 anaschu 06.01.2026 репозиторий https:/ / github. com/ shumilovas/ fungi ветка по-частям. коммит Create переделка под биомассу. txt вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .	Расчёт токов в цепи постоянного тока igorrr37 05.01.2026 / * Дана цепь постоянного тока с сопротивлениями и источниками (напряжения, ЭДС и тока). Найти токи и напряжения во всех элементах. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа и. . .

@Dinkin 783 / 556 / 136 Регистрация: 31.05.2013 Сообщений: 3,145 Записей в блоге: 3
	26.04.2016, 16:22 [ТС]
	Grossmeister, Спасибо за раскрытый ответ. Под обменом данными я имел введу посылка самого запроса на сервер (Компонент TQuery его оптимизирует как то в независимо с какой БД работаем, он сам как надо сделает структуру запроса), а то есть : 1) К примеру есть запрос мего длинный, со всякими там джойнами и внутренними выборками, а TQuery, его оптимизирует и шлет на сервер 2) Другим плюсом является что в самом клиенте мы подставляем только сами переменные к уже готовому запросу, что уменьшает длину самого написания кода. 3) Главный плюс, что не важно с каким типом БД мы работаем, не надо подгонять запросы с MySQL к примеру на MSSQL,достаточно просто сменить провайдера,а TQuery сама уже преобразует запросы. Как пример могу привести Entity Framework. Добавлено через 3 минуты Хотел добавить, что как то встречал в Блоге разработчика FireDac, примеры данной реализации, с замерами. Но к сожалению не придал тогда этому значения, а сейчас даже и блога этого найти не могу. 0

@Dinkin 783 / 556 / 136 Регистрация: 31.05.2013 Сообщений: 3,145 Записей в блоге: 3
	26.04.2016, 17:13 [ТС]
	Grossmeister, Oracle это ваще страшилки, дело не имел с ним, но заочно им уже запугали А по вопросу темы, в общем пока сам толком не знаю, типа "слышал звон....", но точно знаю что есть возможность хотя бы в простых запросах как то сделать универсальную форму, что бы хотя бы подходила и к MsSQL , так и для MySQl для FireDac . 0