Как заставить MySQL хранить данные на диске в зашифрованном виде?

Использовать DES_ENCRYPT/DES_DECRYPT

Альтернатива - использовать криптующую FS

и опять про FOREIGN KEYS

Нашел я упоминание наконец про FOREIGN KEYS. Запустил поддержку InnoDB. И что то не выходит у меня.

Создаю таблицы: create table Computers ( id SMALLINT UNSIGNED DEFAULT 1 AUTO_INCREMENT, name VARCHAR(20), PRIMARY KEY (id) ) TYPE=InnoDB; create table Status ( compid SMALLINT, status SMALLINT, FOREIGN KEY (compid) REFERENCES Computers (id) ) TYPE=InnoDB;

Получаю ошибку: ERROR 1005: Can't create table './test/Status.frm' (errno: 150)

Убираю FOREIGN KEY и таблица создается нормально. Почему? Ответа не в доках, не на сайте я не нашел.

Не знаю..может у тебя с поддержкой InnoDB проблемы? я только что скормил SQL-часть твоего поситнга своему SQL и он даже не икнул :)

mysql> create table Computers ( id SMALLINT UNSIGNED DEFAULT 1 AUTO_INCREMENT, name VARCHAR(20), PRIMARY KEY (id) ) TYPE=InnoDB;
Query OK, 0 rows affected (0.01 sec)

mysql> create table Status ( compid SMALLINT, status SMALLINT, FOREIGN KEY (compid) REFERENCES Computers (id) ) TYPE=InnoDB;
Query OK, 0 rows affected (0.00 sec)

Да чё там, МАЙ СКУЛЬ СОСЁТ !!!

Короче все кто говорит что в MySQL нет транзакций, внешних ключей и других фич - сюда http://www.innodb.com Версии 3.23.х и 4.0.х

на тему проблем с созданием FOREIGN KEY. надо ручками INDEX сделать на поле с FOREIGN ключом. Это где-то в доке было

postgres при всех своих достоинствах, увы не умеет делать запросы между базами данных. что-то типа:

SELECT * FROM database1.tableA INNER JOIN database2.tableZ ON ...

а это весьма сужает область его применимости. а вот MySQL умеет. но он опять же не работат с триггерами и прочими полезностями упомянутыми выше в данном флейме. :) т.е. получаются такие такие вот узкоспециализированные системы. интересно, а какая-нибудь из свободно распространяемых субд умеет делать и то и другое?

> postgres при всех своих достоинствах, увы не умеет делать
> запросы между базами данных
если это так надо, кто мешает написаать пач, который будте длеать это?
принципиально это возможно, но проблемы будут с query planner/optimizer.
Непонятно только, зачем это надо? Мне реально понадобилось лишь 1 раз - когда авторизацию делал.

Запрос с разными ДБ вроде собираются делать (см. TODO). А так, когда такое дело надо было сделал с помощью template DB.

Поставил сабж - РУЛЬ!

Субселект, тригеры, форэйн кейс бля...! Тебе дай волю ты б и отрисовку GUI в один сервер Оракл запихнул. А нафига тогда сервера приложений? DCom, Corba и др... Всему свое место! Моська помоему очень даже на своем месте. А учитывая его кросплатформенность за счет той же самой простоты нет гемора портировать хоть B2B, B2E куда угодно... Минусы есть у всего как и плюсы. А AB Software - огромный сенкс.

Меня забавляет толпа идиотов с криками Oracle сдохнет когда MySQL 4.0 родиться. Мальчики кроме веба есть и другие применения БД. Поймите кроме быстрого доступа есть и сложные запросы и секьюрность данных Пример этому пользователю можно смотреть только вот эти 2 столбца из 10 из этой таблицы нука расскажите как вы это реализуете в MySQL... с учетом того что юзер могет быть умным и сам SQL запросы писать умеет

у меня юсеры имеет право только к вьюхам и процедурам обращаться ни до одной таблицы напрямую я их не пущаю даже на SELECT

А когда я слюшу вопли триггеры и fkey гавно, subselect нахерне нужен мы его через join реализуем ... далеко не всегда это получиться... А про порнографию типа CREATE TEMPORARY table и говорить не охота

> этому пользователю можно смотреть только вот эти 2 столбца из 10 из этой таблицы

Это не есть задача для субд. Если где-то это реализовано, это не означает,
что это лучшее и самое правильное решение.

to nis (*) (2002-06-17 10:15:18.479)

В детский сад! Учиться. Умных словес много, а смысла - ноль.

to anonymous (*) (2002-06-17 11:27:00.094)
> Это не есть задача для субд.

Да ну? Обеспечение секурити данных, хранимых в базе это не задача базы? Тоже в сад...

wild

>>Это не есть задача для субд. Если где-то это реализовано, это не означает, что это лучшее и самое правильное решение. Гмм.. тоды сформулируй задачу СУБД??

Чего? google на MySQL? Наверно все-же кто-то гонит. Нафига там MySQL? полнотекстовый индекс плохо кладется в любую SQL бд: или слишком большая избыточность, или никакой пользы от SQL (если использовать его фактически как хранилище бинарных файлов). Я немного читал про google нет там никаких ссылок про mysql, да и вообще ни про какой sql. http://www7.scu.edu.au/programme/fullpapers/1921/com1921.htm Да и нафига бы сами mysql стали делать fulltext индекс и так долго с ним возяться?

Дык есть это давно.
Запросто. В доке:
GRANT priv_type [(column_list)] [, priv_type [(column_list)] ...]
    ON {tbl_name | * | *.* | db_name.*}
    TO user_name [IDENTIFIED BY 'password']
        [, user_name [IDENTIFIED BY 'password'] ...]
    [WITH GRANT OPTION]

ну если не понятно то так напрмер:

GRANT SELECT (col1,col2) ON database.table TO 'user'@'host';

Смысл как раз есть. Каждой задаче - свой инструмент. Можно с бабой своим инструментом справиться, а можно и стенобитным орудием. Второе помоему не по назначению будет.

Так что это Вам коллега в сад - учиться.

С год назад в новостях проходила ссылка, что на MySql NASA переходит. За умение _одновременно_ заливать и читать большие записи (> 1 Gb). Как выразился переводчик "потоковое видео". Не знаю перешли или нет, но каждый вибирает то, что ему подходит по "качество/возможности/цена". А поливать всё грязью и флеймить без знаний может любой. Сугубо личное мнение.

Ostrovok

Да какая разница кто быстрее прочитает 1000000 записей. От СУБД нужна не скорость а надежность и предсказуемость. Она должна с одинаковой скоростью читать и 1000000 и 100000000. Да поставь ты FoxPro на хорошую машину для одного пользователя он даст фору любому Oracle но без процедур,ключей,триггеров и прочих примочек :((((. Писал на FoxPro ну и геморой. Сижу на Informix что такое типа переиндексация я и слов то таких не помню. Кто за сервер приложений тому на DBF.

>>Если же вы разработчик, i.e. 'developer', то мне непонятны ваши >>вопросы, касающиеся целостности данных. Или вам удобнее определить >>в каком месте произошел сбой, в в третьем commit'e или во втором >>insert'e, нежели 'отдать' это на усмотрение БД?

вот мне и непонятно, неужеле кому то все же удобно расбрасывать всю валидацию по тригерам и check constrеинам ? Вот я сейчас по пол часа выискиваю где в оракле произошел ексепшен, кто то в системе по пять нехриновых тригеров коскадно запускает. Непроще на своем родном языке в апликейшен сервере всю логику хранить ?

Рульная штука этот MySQL .... где бы доки русские намыть да примеров хороших а то ламером и умру...)))

Простите дятьки что в спор ваш лезу ...))

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

to anonymous (*) (2002-06-17 19:30:18.764)
Причём тут версия СУБД? Лучше скажи, через что клиент будет общаться с твоей системой? Если обыкновенное приложение, то какие проблемы? Если через веб морду - то тут особенности... HTTP не поддерживает обратной связи. Пока клиент не спросит об изменениях, он о них не узнает. Вариант - Java - апплет (или ActiveX). Апплет открывает сокет с твоим "сервером приложений" и по собственному протоколу с ним общается... А какая СУБД будет - это уже проблема сервера приложений.

2 I_one

книжек туева хуча во всех магазинах и на лотках

в постресе есть механизм LISTEN/NOTIFY. это конечно не портируемо, но для асинхронной нотификации об изменениях рулит безумно :-)

   Причём тут версия СУБД? Лучше скажи, через что клиент будет общаться с
   твоей  системой? Если обыкновенное приложение, то какие проблемы? Если
Клиент - гуевый (на gtk).
   через  веб морду - то тут особенности... HTTP не поддерживает обратной
   связи.  Пока  клиент  не  спросит  об  изменениях, он о них не узнает.
Поддерживает - называется http push (дерьмо по имени IE его не поддерживает,
только мозилла).
   Вариант  - Java - апплет (или ActiveX). Апплет открывает сокет с твоим
   "сервером  приложений" и по собственному протоколу с ним общается... А
   какая СУБД будет - это уже проблема сервера приложений.
Вот я про это и говорю - без серверов приложений не обойтись.

> Если через веб морду - то тут особенности... HTTP не поддерживает обратной связи.

HTTP вообще ничего не поддерживает ;) А вот браузеры некоторые могут:
http://wp.netscape.com/assist/net_sites/pushpull.html

> Обеспечение секурити данных, хранимых в базе это не задача базы? Тоже в сад...

Секьюрити модель очень примитивна даже в самых дорогих субд. Часто она конфликтует
с функциональностью. Скажем, есть служебная таблица, которая для юзеров должна быть
read-only за исключением одной нечастой операции. Как быть? Такие проблемы разрешает
сервер приложений.

<offtopic> Здесь уже обсуждались достоинства и недостатки СУБД. SQL и sqlbased СУБД есть узкоспециализированые инструменты -> ими весьма удобно решаются задачи, для которых они(инструменты) разрабатывались и совершенно отвратительно решаются задачи, требующие немного большего, чем описано в спецификации.

Популярные СУБД *не подходят* для реализации сколько-нибудь сложной логики встроеными средствами. Тут нужен сервер приложений или просто умное приложение на других языках/инструментах.

Они *не подходят* для интерфейсов в стиле "человек сидит и ждет событие". Это вообще ублюдочная идея. Человек должен работать, а не смотреть на экран в ожидании событий. Правда, иногда и такое нужно.

Зато они дадут фору чему угодно при решении задачи, требующей (относительно) несложной обработки данных, хорошо описываемых реляционной моделью с (относительно) простыми ограничениями целостности и имеющих адекватные средства в используемой СУБД(**). А таких данных очень много. </offtopic> (**) У MySQL этих средств (?пока?) намного меньше, чем в том же Postgres/Oracle/Informix/...

>>Скажем, есть служебная таблица, которая для юзеров должна быть
read-only за исключением одной нечастой операции. Как быть? Такие проблемы разрешает
сервер приложений.

Да ну :)
я так понимаю понятие процедур. вьюверов вам не знакомо...
что мешает сделать два вьювера один на селект, другой на инсерт... :) либо же написать тригер типа befor insert(update) и в нем реализовать ваши проверки или ваше написать все что угодно, вплоть до игнорирования инсерта(апдейта).
Апликайшен сервер есть штука хорошее, но видать не все правильно трактуют его применение.

>>Популярные СУБД *не подходят* для реализации сколько-нибудь сложной логики встроеными средствами.

ты это серьезно??
я понимаю что PL/SQL и механизм exception непостижимо сложен для некоторых, а oбъектных типов, наследования и написания методов многие бояться как огня, но надеюсь java то подходит для реализации бизнес логиги?? Если так не считаешь, то назови язык на котором бизнес логику реализовывать удобнее/быстрее.

Вы бы что-ли книжки там, или форумы какие почитали.. перед такими голословными утвержденеиями.

ifconfig: ты это серьезно??

Там по тексту разбросано слово "относительно":-) Это означает, что многое реализовать можно, но не так удобно как на (лучший язык-offtopic). Тут у меня есть процедура загрузки текстового файлика в таблицу. С относительно тривиальной логикой (по непонятным причинам на PL/SQL) ~ 500 строк кода, в python реализуемая в ~ 10 строк. Это по твоему удобное средство(для этой конкретной задачи)?

Не спорю, есть задачи для которых PL/SQL вполне достаточно и удобно. Есть сервера, в которых кроме PL/SQL можно пользовать другие языки(аж 3 ?).

Я утверждаю, что есть задачи, которые, будучи реализованы другими средствами, будут иметь в несколько раз меньший обьем кода->ошибок->проблем в сопровождении.

Чем навороченей БД, тем больше можно запихнуть в нее. Но стоит ли это делать в *любом* случае?

>>500 строк кода, в python реализуемая в ~ 10 строк. Это по твоему удобное средство(для этой конкретной задачи.

количество строк кода очень слабый аргумент, тем более как эти строки то считать :) Есть еще удобство написания и понятие стандарта. Кстати, пример кинуть можешь, а то я очень слабо верю когда кидаються пропорциями типа 500 vs 10. Тем более что основная часть что PL/SQL, что другога кода есть SQL запросы.. Они то одинаковую длину имеют.

>>несколько раз меньший обьем кода->ошибок->проблем в сопровождении.

А ошибки то тута причем. Если ты сделал ошибку в логике то язык реализации тут очень отдалено относиться.
Насчет удобства спорить не стану, самый удобный язык тот, который хорошо знаешь.

>>Чем навороченей БД, тем больше можно запихнуть в нее. Но стоит ли это делать в *любом* случае?
Не вижу причин этого не делать. При этом правда получаються непортируемые апликухи, но! оракл есть почти под все известные платформы.. (правда ша будут кричать что под ZX-ZPECTRUM нету:) посему портирование прикладухи вместе с ораклом проблем вообще не вызывает, никаких. А портировать апликуху на другой SQL сервер... гм. а Зачем??

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

"Сама" не появится. Есть много вариантов :
- Через триггеры befor update/insert/delete выставлять глобальную переменную
Tablica_imja_tablici_izmenilas = 1 , на узерском приложении проверять значения
этих переменных с заданной периодичностью.
- В некоторых СУБД есть средства "нотификации". В частности - Interbase.
- другие варианты ;)

2 интерфейсу ( ifconfig ;) Вьюхи не всегда помогают. Если view состоит из выборки из нескольких таблиц, оно само не обновляется. Обновлять через триггеры. А если таблиц
много, и их размеры немаленькие, то это занятие становится очень ресурсоемким для сервера :(

nlo

2 ifconfig

>При этом правда получаються непортируемые апликухи, но! оракл есть почти под все >известные платформы..
Насколько я помню, 9 будет поддерживаться только на Linux, Win, HPUX платформах. Все.

>А портировать апликуху на другой SQL сервер... гм. а Зачем ?

А приходят ребята с MS/ Oracle , и втюкивают - вы , там сервачков интелевых подкупите,
вынь/линукс поставите, выкините свой дорогущий мэйнфрэйм/шпукс/альфа сервер, быстрота, кластеризация, красота ...... и.т.д.
Есть примеры из жизни ...

nlo

ifconfig-у

>количество строк кода очень слабый аргумент, тем более как эти строки

Не очень. Каждый набиваемый символ отнимает время и увеличивает вероятность ошибки в коде(хотя бы опечаток). Каждая введенная строка затрудняет понимание того, что написано, и поиск нужного в нем.

>Есть еще удобство написания и понятие стандарта.

Удобство написания и длинна кода обратно пропорциональны - кто любит работать руками? А стандарт - это очень относительно. Любой язык можно считать стандартом - если его реализация компилится где попало.

>пропорциями типа 500 vs 10. >Тем более что основная часть что PL/SQL, что другога кода есть SQL запросы..

Это в идеальном мире :-). А там 2 SQL-запроса. Остальное - определение переменных(штук 200); field_xxx=substr(2,3); и проверки значений (if; бросок исключения; endif - 3 строки). 1е в питоне не нужно, второе и третье в большинстве случаев пишется: "fields=re.match('длинный регексп').groups()" - одной строкой, если без комментариев.

>Насчет удобства спорить не стану, самый удобный язык тот, который хорошо знаешь.

Это только в случае, если лень учиться :-) А если знаешь несколько - то зависит от задачи.

>Не вижу причин этого не делать.

обьем кода, скорость написания-отладки, простота сопровождения(если сопровождает не автор программы должны быть максимально прозрачны)

В том же примере(в 500 строк) я попытался отследить логику и через 5 мин. бросил. И если начальство не скажет(а оно не скажет) то второй раз не полезу. А если оно опять невзработает, а автор окажется в командировке|отпуске, будет плохо.

>>Вьюхи не всегда помогают. Если view состоит из выборки из нескольких таблиц, оно само не обновляется. >>Обновлять через триггеры. А если таблиц
>>много, и их размеры немаленькие, то это занятие становится очень ресурсоемким для сервера :(


Я дал ответ на то как выйти из конкретной ситуации. (Скажем, есть служебная таблица, которая для юзеров должна быть read-only за исключением одной нечастой операции. Как быть?)

когда пишуться вьюверы для нескольких таблиц пользоваться инсертом можно не всегда, но есть куча других способов. К примеру процедуры.. Передаешь им значения, а они сами решают куда их инсертить.
Кстати, еше лучше избегать таких ситуаций, инсертитьь в join таблицы.
Насчет быстродействия тригеров.. Но во первых их мона в натив откомпилить. Во вторых что есть "напряжно" для сервера? понятие весьма относительное.

Врядли поддержка 9 ограничеться теми платформами которые ты упомянул. Не уверен, но помоему на SPARC девятка была с самого начала.
А насчет ребят, ну так это бизнес. а что ты ожидал от них услышать.

Кстати, тривиальный поиск по гугелю порказал что 9 вполне себе на минфреймах нехило живет
http://www.oracle.com/features/9i/benchmarks/index.html?ad_benchmark_bv.html

2 ifconfig
Полностью согласен!
Наверное, приближенная к идеалу БД так и должна выглядеть - для пользователя (или
application server) открыты только вьюшки и execute на процедуры.

А ресурсоемкость - на чистой OLTP задачке (очень много инсертов/апдейтов, быстрые select-ы) такой подход (с view) , к сожалению, не сработает.

Да, а насчет поддержки разных платформ Ораклом - это я что-то перемудрил. Просто проскакивала недавно подобная информация. Быстро найти не получилось :(
То что под Novell Ораклов выпускаться больше не будет - это точно.

nlo

> Я дал ответ на то как выйти из конкретной ситуации. (Скажем, есть служебная таблица, которая для юзеров
> должна быть read-only за исключением одной нечастой операции. Как быть?)

Мне кажется, сэр пропустил одно важное слово - "нечастой". Дальше понятно?

>>Мне кажется, сэр пропустил одно важное слово - "нечастой". Дальше понятно?

если честно, то нет. Не сочтите за труд, излиться мыслею по древу как в вашем понимании должна выполняться
"нечастая" изменение таблицы... И в чем собственно разница то.. (а Вашем понимании)

>Рульная штука этот MySQL ....
>где бы доки русские намыть да примеров хороших а то ламером и умру...)))
>Простите дятьки что в спор ваш лезу ...))

Нее... Ламером помирать обидно :)

http://www.books.ru/shop/books/5872

Яргер, Риз, Кинг
MySQL и mSQL. Базы данных для небольших
предприятий и Интернета

издательство: Символ-Плюс
вышла в июле 2000
ISBN 5-93286-010-3
560 страниц

Хороший перевод О'Рейлевской книжки






qRGER, rIZ, kING

http://www.books.ru/shop/books/5872

2ifconfig (*) (2002-06-18 15:20:37.291)
Что непонятно? Твой триггер будет молотить каждый insert/update; таких
срабатываний может быть сотни тысяч. А реально нужно _один_ раз в сутки.
Вот здесь твои триггеры сосут. Впрочем не только триггеры...

>>Что непонятно? Твой триггер будет молотить каждый insert/update; таких
срабатываний может быть сотни тысяч. А реально нужно _один_ раз в сутки.

Так еще раз читаем.
>>Скажем, есть служебная таблица, которая для юзеров
>> должна быть read-only за исключением одной нечастой операции. Как быть?

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

На свой селект, которых у тебя сотни тысяч, напиши другой вьювер.

Неужели это так сложно?

>>Вот здесь твои триггеры сосут. Впрочем не только триггеры...
Но они не мои. Насчет сосут, оставлю без коментариев.

2ifconfig (*) (2002-06-20 00:34:58.591)
Криво и непортабельно. Твой Oracle сама по себе несекьюрная софтина (смотри securityfocus),
и лично я на него не стал бы закладываться в долгосрочном плане. Так, для баловства только.

>>Криво и непортабельно.
Бр... а что вьверы и тригеры есть только в Оракле?? Скорее всего сервер таблиц не может претендовать на звание
СУБД не имея подобных вещей. Кроме того, а зачем что-то портировать с Оракла?? Только не надо говорить за деньги. В бизнес проектах это второстепеный фактор. (Кстати, я так подозреваю, что многие просто не знают стоимости оракловских лиценззий, просто кричат ДОРОГО!. так для поддержания разговора наверное)

>>Твой Oracle сама по себе несекьюрная софтина (смотри securityfocus),
Эх, если бы Оракл был мой :))
Насчет секурности читай тред повыше, а потом тащи сюда реальный эксплоит с помошью которого я могу
получить данные с сервера конкурентов. Если у тебя таких эксплоитов нет, тоды не бросайся словами которые плохо понимаешь. Дыры, они разные бывают, зачастую только в теории.

>>и лично я на него не стал бы закладываться в долгосрочном плане. Так, для баловства только.
Гм.. Оралу идет 26 год.. (Скорее всего, больше чем вам). Старше Оракла, только DB2..
И на что вы уважаемый собрались закладываться?? нужто на сабж? которому без году неделя...
Кроме того это продукты разного класса и назначения.
Так что не смешите народ.

> что вьверы и тригеры есть только в Оракле??

есть вьюверы только на чтение. Последний оракл не видел, а в 7-ом так и было.

> а зачем что-то портировать с Оракла??

Затем, что не кажому клиенту можно втюхать оракл вместе с продаваемой бухгалтерией.
Он скажет: "мы отдали $$$$ за другой сервер DB, спортируйте плиз под него, тогда поговорим".

> многие просто не знают стоимости оракловских лиценззий,

В районе стоимости новой приличной иномарки. Смотря сколько клиентов.

> тащи сюда реальный эксплоит

Любой реальный взломщик найдет применение для buffer overflow, которых у оракла
как у собаки блох.

> Оралу идет 26 год.

Ну да, а спросить тебя назвать хотя бы 26 известных проектов на оракле в России,
наверное не сможешь ;) Вот тебе и ответ про возраст. А я старше, однако...

>>Затем, что не кажому клиенту можно втюхать оракл вместе с продаваемой бухгалтерией.
>>Он скажет: "мы отдали $$$$ за другой сервер DB, спортируйте плиз под него, тогда поговорим".

Портирование большого проекта стоит гораздо дороже лицензий.

>>В районе стоимости новой приличной иномарки. Смотря сколько клиентов.
Хватит кидаться догадками.
Вот здесь http://oracle.ukrsat.com/store.php?m=licence есть лицензия на английском и русском
Вот здесь http://oracle.ukrsat.com/store.php?m=14 есть ЦЕНА.
Для ленивых выписка

----------------------------------------------
Oracle Database Standard Edition
Oracle Database Standart Edition предоставляет cервер базы данных для рабочих групп. В состав сервера Oracle Database входит интегрированный набор средств тиражирования, репликации и управления.
Количество именованных пользователей (Named user) 5
Цена: 12 447,60 грн.
-----------------------------------------------

12 447,60 грн. = ~ 2200$ -> 450$ на одно рабочей место.

Реально даже 400-420.. Что СОПОСТАВИМО с стоимостью компа или месячной зарплатой того же бухгалтера.

>>Любой реальный взломщик найдет применение для buffer overflow, которых у оракла
>>как у собаки блох.
Ну и где HOWTO как добыть инфу с сервера конкурента?? или эти реальные взломшики из разряда неуловимых джо?
Без эксплоитов все выше написаное просто гон.

>>Ну да, а спросить тебя назвать хотя бы 26 известных проектов на оракле в России,
А зачем известные? Кажый пищет сам под себя. Или нанимает чтоб написали. Ибо совт подобного плана без разработчиков ничего не стоит. Нужны решения, которые надо установить, обучить персонал, а потом еше пол -года год дописывать под конкретные нужды.

Я не назову 26. Но у меня 2. Один большой, другой поменьше. В нашем городе я знаю еще по крайней мере 3 проекта. Вероятно около 20 о которых я не знаю только в нашем городе.
Я считаю что это не мало.

> Есть сервера, в которых кроме PL/SQL можно пользовать другие языки(аж 3 ?).

Ну, кстати говоря, Postgres умеет tcl и набор его языкор расширяем...

Хотя, наверное, писать свой интерпретатор -- тот ещё геморрой

С уважением -- Смоляное Чучелко

> Есть сервера, в которых кроме PL/SQL можно пользовать другие языки(аж 3 ?).

Ну, кстати говоря, Postgres умеет tcl и набор его языкор расширяем...

Хотя, наверное, писать свой интерпретатор -- тот ещё геморрой

С уважением -- Смоляное Чучелко