Здравствуйте, Merle, Вы писали:
M>Нет такой проблемы. Точнее это проблема непротиворечивого представления объекта, и она вылезет в любом случае. M>Проблема в том, что семантика меняется, а цифры остаются те же. И надо использовать те же цифры, но по другому. А если завязываться на семантику, то использовать те же цифры будет очень проблематично.
Именно. Проблемы непротиворечивого представления объекта (или данных все равно). Я согласен с Дейтом что разработчиков SQL увело в сторону, и они забыли именно о непротиворечивом представлении объекта, и ослабили условие на primary key. У них повело не просто систему отображения данных на сущности, у них повело даже сам механизм выполнения SQL запросов.
M>Поэтому к данным надо относиться именно как к данным, завязываясь (на низком уровне) на их семантику только в самом крайнем случае.
Констраинт — это семантика. Введение доменов — также семантика.
Я никогда не оспаривал вопрос в том, что в БД не должно отражаться поведение объектов, но семантика данных (а это свойства сущности) все таки есть.
GZ>>У тебя генерятся гигабайты информации. Притом избыточные гигабайты. И при этом ты говоришь об эффективности? M>Именно. Гигабайты по нонешним меркам — не объем, да и уйти от избыточности не сложно.
Да нет. Уйти — танца с бубном не избежать. Либо отойти от реляционки в чего-нибудь типа Data Mining(Data Warehouse) вместе с OLAP.
GZ>> Так почему сейчас нас накормили полумерами? M>Можешь предложить вариант лучше?
Для реляционки? Конечно да. Не секрет что большинство современных БД строку на физ. уровне хранят как список полей. Для Time Series — это в самый раз. Хранить только те данные которые нужны. В заголовке таблицы — хранить ссылки на актуальные на последний момент записи для каждого столбца. Это некоторый отход от реляционной модели, но проблем несовместимости не вижу.
Что касается иерархии, то хранить именно иерархию. И необязательно в таблице, и необязательно явно. Так чтобы можно было делать нерекурсивные запросы. Это потребует некоторых ресурсов от БД, но и выйгрыш будет значительный.
Здравствуйте, GlebZ, Вы писали:
GZ>Я согласен с Дейтом что разработчиков SQL увело в сторону, и они забыли именно о непротиворечивом представлении объекта, и ослабили условие на primary key. У них повело не просто систему отображения данных на сущности, у них повело даже сам механизм выполнения SQL запросов.
Их конечно увело в сторону, но вовсе не по этому, а скорее даже наоборот.
GZ>Да нет. Уйти — танца с бубном не избежать. Либо отойти от реляционки в чего-нибудь типа Data Mining(Data Warehouse) вместе с OLAP.
Да никаких танцев, не больше чем обычно, а OLAP таже реляционка только в профиль...
M>>Можешь предложить вариант лучше? GZ>Для реляционки?
Чем реляционка.
GZ>Конечно да. Не секрет что большинство современных БД строку на физ. уровне хранят как список полей.
Как запись с заголовком, сплошным блоком.
GZ> Для Time Series — это в самый раз. Хранить только те данные которые нужны. В заголовке таблицы — хранить ссылки на актуальные на последний момент записи для каждого столбца.
Зачем??
GZ> Это некоторый отход от реляционной модели, но проблем несовместимости не вижу.
Пересть реляционной модели в ее универсальности. Было много попыток как-то чуть-чуть ее переделать под некоторые особенные классы задачь, ни одна из них успехом не увенчалась.
GZ>Что касается иерархии, то хранить именно иерархию. И необязательно в таблице, и необязательно явно. Так чтобы можно было делать нерекурсивные запросы. Это потребует некоторых ресурсов от БД, но и выйгрыш будет значительный.
Во-первых выигрыш если и будет, то не значительный, а во-вторых, опять смотри предыдущий абзац про универсальность.
Ну не нужны, как оказалось на практике, только иерархические запросы. Все остальное проседает на столько что пользоваться этим невозможно.
GlebZ wrote:
> VSS и SVN — тоже по сути хранят данные. Но реляционных решений, я > что-то не видал.
Кстати, до недавнего времени SVN использовал для хранения данных
реляционную BerkeleyDB. У них даже схема данных была нарисована в доке.
Сейчас они переехали на свой велосипед, жестко заточеный под их схему.
> Или например иерархические справочники. Я понимаю что решений хоть > отбавляй. Их действительно много и из разных красок. Но сама > реляционка не поддерживает их.
Поддерживает, например можно представить иерархию таким образом:
1. Корневой узел задается числом 1/2 (т.е. 0.5).
2. Его левый ребенок задается числом 1/4.
3. Правый ребенок — числом 3/4.
4. Левый ребенок левого ребенка корневого узла будет задаваться числом 1/8.
И так далее рекурсивно.
При такой схеме запросы "найти всех (левых/правых) детей узла X" будут
выражаться в виде обычных сравнений. А если еще скомбинировать это с
классической схемой задания иерархии с помощью обратных указателей на
родителя — то вообще все прекрасно получается.
> 3. О том что при сращивании объектной модели и реляционной приходится > плясать с бубном, уже наверно говорить не стоит.
Стоит. Так как хорошие нормализованые модели БД прекрасно ложаться на
объекты.
Здравствуйте, ironwit, Вы писали: B>>Если быть до конца честным, бледное подобие таких движков есть, а именно, я говорю о алгоритмических языках, встроенных в СУБД. Конечно, GUI на них писать пока ещё рано... Хотя есть PostgreSQL, где границы между своим и чужим ЯП практически стёрты. I>Можно ли подробнее развить тему?
Процедуры/функции (триггера в т.ч.) могут быть написаны на C или на любом другом языке, если интерпретатор для него подключен к серверу.
PostgreSQL allows user-defined functions to be written in other languages besides SQL and C. These other languages are generically called procedural languages (PLs). For a function written in a procedural language, the database server has no built-in knowledge about how to interpret the function's source text. Instead, the task is passed to a special handler that knows the details of the language. The handler could either do all the work of parsing, syntax analysis, execution, etc. itself, or it could serve as "glue" between PostgreSQL and an existing implementation of a programming language.
...
There are currently four procedural languages available in the standard PostgreSQL distribution: PL/pgSQL (Chapter 35), PL/Tcl (Chapter 36), PL/Perl (Chapter 37), and PL/Python (Chapter 38).
Здравствуйте, Merle, Вы писали:
GZ>> Это некоторый отход от реляционной модели, но проблем несовместимости не вижу. M>Пересть реляционной модели в ее универсальности. Было много попыток как-то чуть-чуть ее переделать под некоторые особенные классы задачь, ни одна из них успехом не увенчалась.
Это еще почему? Как-то решили сделать протокол, чтобы можно было распространять данные без клиента БД. Ну и придумали XML. Приделали так, сказать собачке хвост. А потом оказалось. что xml несколько больше чем протокол передачи данных. И не очень-то натягивалось на реляционку. До этого, реляционщики закрывали глаза на слабоструктурированные данные. Ну храните в блобье, пользуйте вручную, а мы о них не знаем, и ведать не ведаем. Не наши проблемы. А тут, приспичило. Ну очень хочется, и юзверя требуют. Вот и начали приделывать к реляционке слабоструктурированный xml. Хвост начал махать собачкой.
Здравствуйте, Merle, Вы писали:
GZ>>Да нет. Уйти — танца с бубном не избежать. Либо отойти от реляционки в чего-нибудь типа Data Mining(Data Warehouse) вместе с OLAP. M>Да никаких танцев, не больше чем обычно, а OLAP таже реляционка только в профиль...
Из одинакового — только автор, и то что некоторые версии OLAP может использовать реляционку для хранения своих данных.
M>>>Можешь предложить вариант лучше? GZ>>Для реляционки? M>Чем реляционка.
Сервер БД который встроен в сервер приложений. Однозначно должен быть OODB(который не плодит модели). Должен держать возможность хранения слабоструктурированных данных. Должен быть быстрый как декларативный так и навигационный доступ. Все встроенные сервера приложений в реляционку слишком ограничены возможностями БД(я сужу по нетовскому).
GZ>>Конечно да. Не секрет что большинство современных БД строку на физ. уровне хранят как список полей. M>Как запись с заголовком, сплошным блоком.
Без разницы. Главное что структура переменной длины.
GZ>> Для Time Series — это в самый раз. Хранить только те данные которые нужны. В заголовке таблицы — хранить ссылки на актуальные на последний момент записи для каждого столбца. M>Зачем??
Получение последних данных — наиболее частая операция.
GZ>> Это некоторый отход от реляционной модели, но проблем несовместимости не вижу. M>Пересть реляционной модели в ее универсальности. Было много попыток как-то чуть-чуть ее переделать под некоторые особенные классы задачь, ни одна из них успехом не увенчалась.
Это уже в соседнем сообщении.
M>Ну не нужны, как оказалось на практике, только иерархические запросы. Все остальное проседает на столько что пользоваться этим невозможно.
Никто и не говорил о только иерархических запросах. И вообще я не говорил о выходе за пределы реляционных запросов. Разговор о том, что при рекурсивных запросах на большом количестве данных, БД проседать будет. Если хранить иерархию, и нерекурсивно получать полные пути к элементам, то проседать не будет. Только всего-лишь и разница. А хранение иерархии — в принципе можно и реляционно организовать(правда может некоторая управляемая рекурсия для очень глубоких иерархий получится). А если к этому подключить аппарат оптимизации запросов, то совсем хорошо будет.
Здравствуйте, dmz, Вы писали:
dmz>Н-да? Можно примеры реализации каких-нибудь больших систем на основе OODBMS ? Что-нибудь типа биллинга, dmz>еще-то нибудь? Вот у нас, например, тут на оракле стоит препейдная система (ну, биллинг, короче — что бы не заморачиваться) dmz>- там есть таблица с количеством записей — сотни миллионов. Работает в почти-рилтайме, жестко соблюдается максимальное время dmz>ответа для некоторых операций (менее 5 секунд). Что-нибудь подобное можно организовать на OODBMS?
Да легко. Даже были примеры. Для операционных задач со сложной структурой OODBMS быстрее справляется чем RDB. Поищи по форуму, там были ссылки. В том числе благодаря навигационному доступу.
Да и к тому же, существует миф что ООDBMS — отрицает реляционное хранение. В большинстве сегодняшних продуктов это не так. ООDB — использует на физике именно реляционное хранение. И оптимизация запросов именно по Киму + дополнительные фичи.
Здравствуйте, GlebZ, Вы писали:
GZ>Это еще почему?
По совокупности обстоятельств.
GZ> Как-то решили сделать протокол, чтобы можно было распространять данные без клиента БД. Ну и придумали XML.
При чем тут XML?
XML сама по себе конструкция достаточно универсальная, но для хранения больших объемов данных с возможностью произвольной выборки — малопригодная.
И что самое забавное, для реализации XQuery документ XML раскладывается внизу все равно на реляционное представление, так что не угадал ты с примером...
GZ>Сервер БД который встроен в сервер приложений. Однозначно должен быть OODB(который не плодит модели). Должен держать возможность хранения слабоструктурированных данных. Должен быть быстрый как декларативный так и навигационный доступ. Все встроенные сервера приложений в реляционку слишком ограничены возможностями БД(я сужу по нетовскому).
Не, я тоже конечно могу идеальную сферическую систему в вакууме придумать, но толку-то. Никогда не задавался вопросом, почему до сих пор ничего подобного не сделали?
Сейчас тенденция скорее сервера приложений в БД встраивать, причем в реляционные, а не наоборот, и это не с проста.
GZ>Получение последних данных — наиболее частая операция.
Думаешь хранение ссылок ее ускорит? Это тот же индекс, только в профиль, так почему бы обычный индекс не задействовать.. Не надо обходные маневры на ровном месте придумывать.
GZ>Никто и не говорил о только иерархических запросах.
Тогда в чем проблема?
Вывод: Задачи с иерархией не проблема для реляционных БД.
Здравствуйте, Merle, Вы писали:
M>XML сама по себе конструкция достаточно универсальная, но для хранения больших объемов данных с возможностью произвольной выборки — малопригодная.
Поговорим о Sedna XML или еще какой-нибудь XML БД? Ты им это не рассказывал? А там между прочим нехилые люди сидят. Теоретики БД.
M>И что самое забавное, для реализации XQuery документ XML раскладывается внизу все равно на реляционное представление, так что не угадал ты с примером...
Не подменяй понятия. Если там используется реляционное исчисление или похожее, это не значит что это именно реляционка. Алгебру моноидов тоже можно назвать продвинутым реляционным исчислением. Только почему-то не называют. Не удивлюсь если MSSQL реализовал XQuery запросы только в рамках своего аппарата. Но вообще-то, для построения эффективного вычисления XQuery запросов нужны дополнительные команды. Ну хреново, когда вложенный объект, которые безусловно можно математически описать реляционным join, получают через join. Неэффективно.
Вообще, уже лет пять большая часть прогрессивного сообщество которое занимается развитием БД, работает именно над запросами к XML. И те работы которые я видел, уже давно вышли за рамки стандартного реляционного аппарата современных реляционок. Развитие в рамках реляционной модели данных уже достигло максимума. Быстрее этого уже не будет(хотя есть еще некоторые недоработки в области индексов). Для дальнейшего развития давно уже ослабили требования реляционнок на структурированность данных.
Здравствуйте, Merle, Вы писали:
M>Сейчас тенденция скорее сервера приложений в БД встраивать, причем в реляционные, а не наоборот, и это не с проста.
Неужели денег хотят?
M>Тогда в чем проблема? M>Вывод: Задачи с иерархией не проблема для реляционных БД.
Ага, а проблема архитектора. И притом настолько частая, что возникает в любом мало-мальски большом приложении.
Здравствуйте, GlebZ, Вы писали:
GZ>Поговорим о Sedna XML или еще какой-нибудь XML БД? Ты им это не рассказывал? А там между прочим нехилые люди сидят. Теоретики БД.
Ага и где они сидят? Хоть одно серьезное коммерческое приложение на XML базе в качестве основного хранилища есть?
GZ>Не подменяй понятия.
Не подменяю.
GZ> Если там используется реляционное исчисление или похожее, это не значит что это именно реляционка.
А что же это значит?
GZ> Не удивлюсь если MSSQL реализовал XQuery запросы только в рамках своего аппарата. Но вообще-то, для построения эффективного вычисления XQuery запросов нужны дополнительные команды.
Не в командах дело, а в представлении. Для хранения внутри XML раскладывается в структуру напоминающую обычные реляционные таблицы.
GZ>Ну хреново, когда вложенный объект, которые безусловно можно математически описать реляционным join, получают через join. Неэффективно.
Это кто сказал, что не эффективно? И дело не в описании, а в физической операции. Так вот оказалось, что выгоднее всего для иерархических операций, таки свести их к реляционным и так с ними и работать.
GZ>Вообще, уже лет пять большая часть прогрессивного сообщество которое занимается развитием БД, работает именно над запросами к XML. И те работы которые я видел, уже давно вышли за рамки стандартного реляционного аппарата современных реляционок.
А ты хорошо себе представляешь аппарат современных реляционок? Все что я видел из работ прогрессивного человества сводится к попыткам свести XML к плоским таблицам для большей эффективности.
GZ> Развитие в рамках реляционной модели данных уже достигло максимума. Быстрее этого уже не будет(хотя есть еще некоторые недоработки в области индексов).
Только вот превзойти эту скорость, на широком классе задачь, пока что не получалось ни у кого...
GZ>Для дальнейшего развития давно уже ослабили требования реляционнок на структурированность данных.
Для дальнейшего развития куда?
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, GlebZ, Вы писали:
GZ>>Поговорим о Sedna XML или еще какой-нибудь XML БД? Ты им это не рассказывал? А там между прочим нехилые люди сидят. Теоретики БД. M>Ага и где они сидят? Хоть одно серьезное коммерческое приложение на XML базе в качестве основного хранилища есть?
Во первых, слишком маленький возраст. Для справки, проект System R — разрабатывался, по моему, в течении 8 лет. С 1972-по 1980. Работа Кодда — 68-69гг. Коренная доработка проводилась еще в течении 80'ых(логическая оптимизация, семантическая оптимизация, System R*). Стало более менее мейнстримом в начале 90-ых.
Во вторых, самих баз до фигищи, чуть ли не в каждом продвинутом университете. А пересчитай на пальцах серьезные коммерческие ДБ и сколько лет было развития до того как они стали серьезными.
GZ>> Если там используется реляционное исчисление или похожее, это не значит что это именно реляционка. M>А что же это значит?
А то что подмени термины на отношения и кортежи, и многие формулы будут эквивалентные. Законы физики они и в Африке действуют.
GZ>> Не удивлюсь если MSSQL реализовал XQuery запросы только в рамках своего аппарата. Но вообще-то, для построения эффективного вычисления XQuery запросов нужны дополнительные команды. M>Не в командах дело, а в представлении. Для хранения внутри XML раскладывается в структуру напоминающую обычные реляционные таблицы.
Ну да, именно напоминающую. Реляционная модель — строгая модель как и любая другая математическая модель. Все что не входит в ее алфавит, уже не входит в реляционную модель. А алфавит небольшой — аттрибут, кортеж, отношение, да может еще что-то придумать можно(сходу не скажу). И достаточно небольшой набор операций. Насколько я знаю, термина связи как таковой там нет. Там только описание трансформаций модели. Там не было в алфавите вложенных таблиц. Отношения все равноправны. Там много чего не было, что сейчас используется.
Насчет альтернативных команд, как тебе такое:
unnest, returns the collection of all pairs (x, y) for each x in X and for each y in x.path that satisfy the predicate p(x, y).
Это базовая алгебра моноидов из Фегараса.
GZ>>Ну хреново, когда вложенный объект, которые безусловно можно математически описать реляционным join, получают через join. Неэффективно. M>Это кто сказал, что не эффективно? И дело не в описании, а в физической операции. Так вот оказалось, что выгоднее всего для иерархических операций, таки свести их к реляционным и так с ними и работать.
Это конкретный случай. Я его специально попытался впихнуть реляционную модель, для того чтобы показать что никаких проблем нет. Ну почти проблем нет.
GZ>>Вообще, уже лет пять большая часть прогрессивного сообщество которое занимается развитием БД, работает именно над запросами к XML. И те работы которые я видел, уже давно вышли за рамки стандартного реляционного аппарата современных реляционок. M>А ты хорошо себе представляешь аппарат современных реляционок? Все что я видел из работ прогрессивного человества сводится к попыткам свести XML к плоским таблицам для большей эффективности.
И да и нет. Плоские таблицы удобны потому как хранение у нас двухмерное. Но реляционная алгебра, как и другая алгебра состоит из четырех частей: алфавит, утверждения, аксиомы, правила вывода. Модель абстрактная, описывает законы а не реализацию. Реализацию потом додумывают. Так вот, вводим термин путь, и мы уже за пределами модели. Это уже другая алгебра. Но она не противоречит предыдущей алгебре.
Если говорить об алгебре Кодда, то она была изменена. Туда были добавлены дополнительные правила вывода(полусоединение, антисоединения и outerjoin и по моему G-Agg). Аксиомы и тем более алфавит были нетронуты. Поэтому это как была реляционка, так ею и осталась, иногда правда называют — расширенная реляционная алгебра.
Это про теорию. А про реализацию могу еще намекнуть, каким образом слабоструктурированный xml будет у тебя индексироваться?
GZ>> Развитие в рамках реляционной модели данных уже достигло максимума. Быстрее этого уже не будет(хотя есть еще некоторые недоработки в области индексов). M>Только вот превзойти эту скорость, на широком классе задачь, пока что не получалось ни у кого...
И не превзойдут. Пока не надо будет выходить за пределы модели, не превзойдут. Ну а поскольку большинство бизнес-задач прекрасно описываются в терминах реляционки, то революция откладывается.
GZ>>Для дальнейшего развития давно уже ослабили требования реляционнок на структурированность данных. M>Для дальнейшего развития куда?
Вперед!!! К заоблачным высотам. К молочным берегам, и кисельным рекам. Ты же не думаешь, что на реляционных базах все остановилось. Сам говорил что не идеально.
Здравствуйте, GlebZ, Вы писали:
GZ>Во первых, слишком маленький возраст.
Более чем.
GZ> Для справки, проект System R — разрабатывался, по моему, в течении 8 лет. С 1972-по 1980. Работа Кодда — 68-69гг. Коренная доработка проводилась еще в течении 80'ых(логическая оптимизация, семантическая оптимизация, System R*). Стало более менее мейнстримом в начале 90-ых.
Для справки. Возраст иерархических БД гораздо больше реляционных, объектные БД пытаются разработать уже лет пятнадцать, XML-ные лет 5-6. Оракл выпустил первую крайне успешную коммерческую реализацию реляционки года за три-четыре, раньше чем IBM очнулась и начала что-то выпускать на основе System R.
Так что времени было более чем достаточно.
GZ> А пересчитай на пальцах серьезные коммерческие ДБ и сколько лет было развития до того как они стали серьезными.
Оракл стал серьезным спустя два-три года после своего появления, при этом это была в принципе первая коммерческая СУБД.
GZ>А то что подмени термины на отношения и кортежи, и многие формулы будут эквивалентные. Законы физики они и в Африке действуют.
Отсюда делаем вывод, что раз действуют законы реляционки, то это реляционка.
GZ>Ну да, именно напоминающую.
"Человек похожий на генерального прокурора ..."
GZ>Реляционная модель — строгая модель как и любая другая математическая модель. Все что не входит в ее алфавит, уже не входит в реляционную модель. А алфавит небольшой — аттрибут, кортеж, отношение, да может еще что-то придумать можно(сходу не скажу). И достаточно небольшой набор операций. GZ> Насколько я знаю, термина связи как таковой там нет. Там только описание трансформаций модели. Там не было в алфавите вложенных таблиц. Отношения все равноправны. Там много чего не было, что сейчас используется.
Отлично. Так вся структура к которой сводится XML при хранении, чудным образом описывается этим скудным аппаратом. (К слову он не такой уж скудный, там есть много того что сейчас не используется, но не о том речь, суть-то сохранена)
Все что сейчас хоть как-то имеет широкое практическое применение в области БД, построено на реляционной модели, вне зависимости от ее строгости и расширенности.
GZ>Насчет альтернативных команд, как тебе такое:
А при чем тут команды? Хоть горшком назови... Не смущает, что в третьем шарпе синтаксис очень сильно совпадающий с SQL-м работает, тем не менее, по иерархическим запросам?
GZ>Я его специально попытался впихнуть реляционную модель, для того чтобы показать что никаких проблем нет. Ну почти проблем нет.
Ну вот и договорились..
GZ>И да и нет. Плоские таблицы удобны потому как хранение у нас двухмерное. Но реляционная алгебра, как и другая алгебра состоит из четырех частей: алфавит, утверждения, аксиомы, правила вывода. Модель абстрактная, описывает законы а не реализацию. Реализацию потом додумывают. Так вот, вводим термин путь, и мы уже за пределами модели.
Почему это за пределами? Как только мы описываем путь в терминах существующей модели, исчезает необходимость за пределы оной модели выходить..
GZ>Это про теорию. А про реализацию могу еще намекнуть, каким образом слабоструктурированный xml будет у тебя индексироваться?
Ты лучше намекни откуда ты взял, что XML слабоструктурированный... Он на самом деле существенно более структурированный нежели реляционная модель. А индексироваться он будет очень просто, как только мы сведем его к реляционке проблем не останется. Собственно так и поступают.
Здравствуйте, Mazay, Вы писали:
M>Честно говоря не вижу принципиальных препятствий для хранения объектов в БД в виде подобном тому, в каком они хранятся в оперативной памяти.
Если оставить СКВВ в покое, то как будет происходить процесс изменения структуры объектов. Например, добавили мы, удалили или изменилии тип поля в объекте. Что будет просиходить при чтении объекта старой структуры? Куда денутся убитые поля, откуда появятся новые и кто будет заниматься конвертацией изменённых?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, GlebZ, Вы писали:
GZ>VSS и SVN — тоже по сути хранят данные. Но реляционных решений, я что-то не видал.
Source Gear Vault — отличается умом и сообразительностью, и на порядок более высокой производительностью чем вышеобозначенные (особенно первый) товарищи.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, beroal, Вы писали:
B>Здравствуйте, ironwit, Вы писали: B>>>Если быть до конца честным, бледное подобие таких движков есть, а именно, я говорю о алгоритмических языках, встроенных в СУБД. Конечно, GUI на них писать пока ещё рано... Хотя есть PostgreSQL, где границы между своим и чужим ЯП практически стёрты. I>>Можно ли подробнее развить тему? B>Процедуры/функции (триггера в т.ч.) могут быть написаны на C или на любом другом языке, если интерпретатор для него подключен к серверу.
Мы уже победили, просто это еще не так заметно...
Хотя есть PostgreSQL, где границы между своим и чужим ЯП практически стёрты. 
Если нам не помогут, то мы тоже никого не пощадим.
