Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет ringill ([info]ringill)
@ 2006-10-31 20:20:00

Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Low-level stored procedures in Oracle and SQL Server 2005
Речь идёт о процедурах, хранящихся в базе данных и написанных не на SQL.
Они делятся на два класса:

1) «Внутренние» -- исполняемые непосредственно сервером базы данных.

2) «Внешние» -- исполняемые операционной системой, на которой установлен сервер.



Внутренние хранимые процедуры более безопасны и (по крайней мере, в Oracle) быстрее могут обмениваться данными с сервером. Внешние, зато, имеют доступ непосредственно к операционной системе (в обход сервера), и, само собой, их можно писать на C/C++.



Поддержка хранимых процедур в Oracle и SQL Server


Oracle

MS SQL Server
2000

MS SQL Server
2005

Внутренние PL/SQL, Java

Transact SQL
(T-SQL)

T-SQL, .NET
assemblies

Внешние

Есть
(на каждую сессию загружаются отдельным процессом под названием extproc)

Есть. Я не
пользовался.

Есть, но только в
рамках обратной совместимости
.




Оказалось, что в SQL Server 2005 можно писать низкоуровневые внешние процедуры на C/C++,
«оборачивая» их внутренними, работающими в .NET CLR. Для этого нужно
специальным образом настроить
сервер, и указать, что обёртка «небезопасная»:



CREATE ASSEMBLY [name] from [dll file] WITH PERMISSION_SET = UNSAFE;



Сборкам типа UNSAFE позволено вызывать Win32 API, но не более того: низкоуровневые (unmanaged) вызовы вроде malloc() запрещены, поэтому делать обёртку на C++/CLI не имеет смысла.
Но пользоваться механизмом P/Invoke разрешено!
То есть, надо делать обёртку на C# и загружать dll-файл с C или C++-кодом с помощью DLLImport.
Таким образом, низкоуровневые процедуры будут исполняться в адресном пространстве сервера, и при этом беспрепятственно смогут общаться с ОС. На все пользовательские сессии загружается одна копия библиотеки, т.е. она должна поддерживать multithreaded режим. В Oracle, кстати, наоборот -- на каждую сессию в памяти приходится отдельный экземпляр.



Кстати, dll-файл, подлежащий импорту, вовсе не обязательно класть в директорию, прописанную в PATH. Здесь написано, как загрузить его из произвольной директории вызовом
LoadLibrary() из kernel32.dll


(Читать комментарии)

Добавить комментарий:

Как:
(комментарий будет скрыт)
Identity URL: 
имя пользователя:    
Вы должны предварительно войти в LiveJournal.com
 
E-mail для ответов: 
Вы сможете оставлять комментарии, даже если не введете e-mail.
Но вы не сможете получать уведомления об ответах на ваши комментарии!
Внимание: на указанный адрес будет выслано подтверждение.
Имя пользователя:
Пароль:
Тема:
HTML нельзя использовать в теме сообщения
Сообщение: