Построение универсальных запросов к базам в разных СУБД (MS SQL, Oracle, MySql и т.д.)

@8VAid8 · Регистрация: 21.04.2012

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

Приложение имеет 2 слоя: доступа к данным и бизнес-логика. В бизнес-логике выполняются некоторые запросы к базе данных, заранее неизвестной(MS SQL/Oracle/ ../ подключается строкой подключения). В слое доступа к данным имеются подключения и драйверы к требуемым СУБД.
Как написать универсальные запросы, которые бы корректно работали в подключаемых СУБД? Синтаксис SQL в разных базах незначительно различается.
Сохранять таблицы в DataSet запрещается из за возможно большого объёма таблиц.
ORM(LINQ to SQL/Entity Framework) не подходят, т.к. требуют заранее созданные модели данных.
Основным критерием является скорость работы запросов.

@Grossmeister · 29.02.2016, 10:06

Сообщение от 8VAid8

Синтаксис SQL в разных базах незначительно различается.

Уточнение. Незначительно отличается для самых простых случаев. Когда касается чего-то более сложного типа аналитических функций, иерархических запросов, регулярок и проч., то различия становятся весьма значительными. Да что там - даже конкатенация строк в Oracle, MS SQL и MySQL реализована по разному, а это часто используемая вещь.
Не говоря уж о том, что в запросах часто встречаются функции, например, работы с датами, а они специфичны для каждой СУБД, ибо на них никаких стандартов нет.

Сообщение от 8VAid8

Основным критерием является скорость работы запросов.

А это является отягчающим фактором. Нередко один запрос можно написать разными способами. Так вот, один способ будет быстрее работать на одной СУБД, другой способ - на другой.

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

@Defazze · 29.02.2016, 10:34

Действительно, требования весьма противоречивые.

С одной стороны, требуется универсальность.
С другой стороны, нельзя ORM, которые эту самую универсальность могли бы легко предоставить.
И с третьей стороны критичная скорость. А любая ORM неизбежно даст просадку по скорости.

@8VAid8 · 29.02.2016, 12:01 **[ТС]**

В данном случае главная проблема ORM - создание объектной модели(классов) до компиляции. А планируется подключаться к различным таблицам, и структуру знать заранее невозможно.
Нужен генератор sql кода, что-то вроде .NET Dynamic SQL Generator, возможно.

@Defazze · 29.02.2016, 12:08

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

@8VAid8 · 29.02.2016, 13:05 **[ТС]**

Будут передаваться названия таблиц и столбцов в запросы.

@XIST · 29.02.2016, 16:26

EF - меняете только коннектор для доступа

@8VAid8 · 29.02.2016, 18:31 **[ТС]**

XIST, а как быть с заранее создаваемой моделью(классами)? Они неизвестны. EF позволяет не создавать их или делать это во время работы приложения?

@XIST · 29.02.2016, 20:15

8VAid8, что не известно не заметил, но теоретически-то, читать системную схему базы можно, и передавать как-то в один контекст(ну тут подумать, с таблицами понятно) а вот с полями да, но типа как работа с ADO через создаваемый датасет с чтением через XML структуры датасета..... но этож апупеть, стоит ли овчинка

@m0nax · 29.02.2016, 20:18

Сообщение от 8VAid8

Будут передаваться названия таблиц и столбцов в запросы.

т.е запросы будут не сложней select * from * where a = b
тогда все СУБД одинаковые, особенно если фильтры простенькие по числу/строке то точно одинаковы

@8VAid8 14 / 15 / 2 Регистрация: 21.04.2012 Сообщений: 192
		1
	Построение универсальных запросов к базам в разных СУБД (MS SQL, Oracle, MySql и т.д.) 27.02.2016, 18:53. Показов 1807. Ответов 9 Метки нет (Все метки) Приложение имеет 2 слоя: доступа к данным и бизнес-логика. В бизнес-логике выполняются некоторые запросы к базе данных, заранее неизвестной(MS SQL/Oracle/ ../ подключается строкой подключения). В слое доступа к данным имеются подключения и драйверы к требуемым СУБД. Как написать универсальные запросы, которые бы корректно работали в подключаемых СУБД? Синтаксис SQL в разных базах незначительно различается. Сохранять таблицы в DataSet запрещается из за возможно большого объёма таблиц. ORM(LINQ to SQL/Entity Framework) не подходят, т.к. требуют заранее созданные модели данных. Основным критерием является скорость работы запросов. 0

@Grossmeister 4217 / 3058 / 583 Регистрация: 21.01.2011 Сообщений: 13,205
	29.02.2016, 10:06	2
	Сообщение от 8VAid8 Синтаксис SQL в разных базах незначительно различается. Уточнение. Незначительно отличается для самых простых случаев. Когда касается чего-то более сложного типа аналитических функций, иерархических запросов, регулярок и проч., то различия становятся весьма значительными. Да что там - даже конкатенация строк в Oracle, MS SQL и MySQL реализована по разному, а это часто используемая вещь. Не говоря уж о том, что в запросах часто встречаются функции, например, работы с датами, а они специфичны для каждой СУБД, ибо на них никаких стандартов нет. Сообщение от 8VAid8 Основным критерием является скорость работы запросов. А это является отягчающим фактором. Нередко один запрос можно написать разными способами. Так вот, один способ будет быстрее работать на одной СУБД, другой способ - на другой. Так что "универсальные запросы" - вешь слабореализуемая. Хотя идея периодически возникает у разных разработчиков (в основном у тех, кто только начинает работать с БД). 1

@Defazze 325 / 136 / 28 Регистрация: 18.09.2014 Сообщений: 167
	29.02.2016, 10:34	3
	Действительно, требования весьма противоречивые. С одной стороны, требуется универсальность. С другой стороны, нельзя ORM, которые эту самую универсальность могли бы легко предоставить. И с третьей стороны критичная скорость. А любая ORM неизбежно даст просадку по скорости. 0

@8VAid8 14 / 15 / 2 Регистрация: 21.04.2012 Сообщений: 192
	29.02.2016, 12:01 [ТС]	4
	В данном случае главная проблема ORM - создание объектной модели(классов) до компиляции. А планируется подключаться к различным таблицам, и структуру знать заранее невозможно. Нужен генератор sql кода, что-то вроде .NET Dynamic SQL Generator, возможно. 0

@Defazze 325 / 136 / 28 Регистрация: 18.09.2014 Сообщений: 167
	29.02.2016, 12:08	5
	А как планируется создавать некие универсальные запросы, если структура таблиц заранее неизвестна? Пользователь будет создавать запросы на некоем промежуточном языке? 0

@8VAid8 14 / 15 / 2 Регистрация: 21.04.2012 Сообщений: 192
	29.02.2016, 13:05 [ТС]	6
	Будут передаваться названия таблиц и столбцов в запросы. 0

@XIST 1504 / 1052 / 146 Регистрация: 01.10.2009 Сообщений: 3,537 Записей в блоге: 1
	29.02.2016, 16:26	7
	EF - меняете только коннектор для доступа 0

@8VAid8 14 / 15 / 2 Регистрация: 21.04.2012 Сообщений: 192
	29.02.2016, 18:31 [ТС]	8
	XIST, а как быть с заранее создаваемой моделью(классами)? Они неизвестны. EF позволяет не создавать их или делать это во время работы приложения? 0

@XIST 1504 / 1052 / 146 Регистрация: 01.10.2009 Сообщений: 3,537 Записей в блоге: 1
	29.02.2016, 20:15	9
	8VAid8, что не известно не заметил, но теоретически-то, читать системную схему базы можно, и передавать как-то в один контекст(ну тут подумать, с таблицами понятно) а вот с полями да, но типа как работа с ADO через создаваемый датасет с чтением через XML структуры датасета..... но этож апупеть, стоит ли овчинка 0

@m0nax 1274 / 975 / 113 Регистрация: 12.01.2010 Сообщений: 1,971
	29.02.2016, 20:18	10
	Сообщение от 8VAid8 Будут передаваться названия таблиц и столбцов в запросы. т.е запросы будут не сложней select * from * where a = b тогда все СУБД одинаковые, особенно если фильтры простенькие по числу/строке то точно одинаковы 0