Блог

Есть ли возможность объединить TVF/UDF в СУБД с внешней IDE или языком, подобным C? Как это сделать без записи в таблицу?

Я знаю, что есть способ «сопоставления памяти» или способ совместного использования блока памяти

Функция POSIX mmap() , функция Windows OpenFileMapping()

Я использую Windows, так есть ли способ обмена данными с СУБД с помощью сопоставления памяти или совместного использования с чем-то вроде C? Но как бы вы избежали записи в таблицу или файл, используя только память?

Общая память доступна для передачи данных поставщикам SQL и от них. Вам не нужно писать для этого никакого дополнительного кода, если вы используете встроенные драйверы для доступа к вашему провайдеру. Вместо этого вы просто настроили бы драйвер и сервер для использования этого, и ваше приложение должно было бы находиться на том же сервере, что и ваш поставщик SQL.

Драйверы ODBC, доступные для Windows, поддерживают общую память для операций SQL. Чтобы написать код для них на C, вам следует использовать ODBC API для связи с вашим провайдером. Вот ссылка со ссылкой на функцию.

Краткое описание функции ODBC @ MSDN

Также обратите внимание, что существует поддержка больших двоичных объектов для всех поставщиков SQL, которые могут обрабатывать произвольные двоичные данные. Список типов, известных ODBC API, доступен здесь. Нет строгого требования, что результаты вашего заявления должны быть представлены в табличной форме.

Типы данных SQL @ MSDN

С другой стороны, если вас интересует взаимодействие с внутренними объектами SQL на ваших собственных условиях, вы могли бы что-то совместить с помощью расширений к используемой вами службе SQL. Например, MS SQL Server допускает расширения с помощью процедур автоматизации Ole или интеграции с CLR (.net) (доступно в MS SQL Server). Потенциально вы могли бы использовать их make something для передачи данных вне диапазона. Однако ни то, ни другое не так просто создать с помощью чистого решения на языке Си.

Процедуры автоматизации Ole в SQL Server @ MSDN

Интеграция CLR в SQL Server @ MSDN

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

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

И последнее, трудно диктовать поставщику SQL, что ему следует избегать использования хранилища файловой системы. Для MS SQL Server одним из возможных вариантов является принудительное размещение базы данных tempdb в оперативной памяти. Вот статья объемом в КБ с более подробной информацией. Другие СУБД могут иметь аналогичные параметры конфигурации.

INF: когда использовать базу данных tempdb в оперативной памяти

Однако использование дискового хранилища не обязательно является причиной для беспокойства. Я не могу найти хороший пример того, как поставщики SQL управляют балансом оперативной памяти и файловой системы, но один хороший аналог для SQL server — это то, как на Windows влияет использование файлов подкачки. Вот отличная ссылка, которая подробно описывает, как Windows ведет себя при высоких ограничениях работы, и как использование памяти не обязательно соответствует переполнению диска. Также обратите внимание, что приложения, написанные для запуска в Windows, также подвергаются негативному воздействию, когда работа хоста приближается к этим ограничениям.

Расширение возможностей Windows: виртуальная память @ TechNet

СУБД должна быть спроектирована так, чтобы работать так, как вы хотите. Обычные СУБД имеют свои собственные механизмы управления данными, и хотя вы могли бы взаимодействовать с ними через общую память, более вероятно, что вы этого не сделаете. СУБД может хранить большую часть своих рабочих данных в памяти; это зависит от СУБД. Как правило, данные будут поддерживаться дисковым хранилищем.

Чего вы не можете сделать, так это взять произвольную СУБД и указать ей, что она должна взаимодействовать с вашим процессом через общую память. Если она предназначена для этого, то вы можете; в противном случае вы не можете.

Однако, как правило, вы используете ODBC или аналогичный драйвер для доступа к СУБД из вашего приложения, и те, кто реализует драйвер (и СУБД), определяют, как будет происходить межпроцессное взаимодействие.