| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java: Общие вопросы > Дружим с БД без JDBC |
| Автор: Рассада 25.7.2005, 10:37 |
| Добрый день! У меня такая задача: надо осуществить взаимодействие приложения на Java с различными СУБД (MS SQL, MySQL, Oracle) без использования JDBC. Задачу придумал не я, поэтому советы перестать валять дурака мне пока малополезны  . Может, есть какие-нибудь API-библиотеки фирм-производителей СУБД... Хотя боюсь, что работа с каждой СУБД через API принесет с собой кучу хлопот |
| Автор: LSD 25.7.2005, 10:55 | ||||
Для Oracle есть OCI, но она рассчитана на работу с Си, а из Java придется использовать JNI.
Именно табу на JDBC, или стоит задача абстрагироваться от конкретной СУБД? |
| Автор: Рассада 25.7.2005, 11:13 | ||||
Разве это сохранить платформонезависимость?
Задача абстрагирования стоит давно. С этим пока все проблемы решаются. А запрет связан с тем, что JDBC не обладает должной надежностью (без комментариев). В общем, как я понял, хочется им обойтись без использования высокоуровневых функций ODBC, JDBC, OLE DB... Добавлено @ 11:20 Для MySQL нашлось что-то вот здесь: http://www.mysql.com/products/connector/j/. Надо копнуть глубже... |
| Автор: LSD 25.7.2005, 11:21 | ||
OCI реализован для всех платформ на которых работает Oracle. Надо ли будет вносить изменения в Сишную прослойку или достаточно будет ее перекомпилировать под конкретную платформу, я не знаю. А вот Java код можно оставить без изменений. Но работать с OCI то еще удовольствие, библиотека довольно низкоуровневая. Лучше объясни заказчику, что это весьма трудоемко, а результат может быть хуже чем с JDBC. |
| Автор: batigoal 25.7.2005, 14:01 | ||
Это JDBC-драйвер |
| Автор: Рассада 25.7.2005, 15:15 |
. Так точно, на сайте это написано  . Есть еще MySQL API для C++ "mysql++". Не слишком простые пути вырисовываются по грядущей реализации... |
| Автор: SmaLL 25.7.2005, 16:16 | ||
Интересно, а откуда такая информация? 2All А что действительно не обладает?  |
| Автор: AntonSaburov 25.7.2005, 16:25 | ||
Да вообщем-то как любое приложение, которое использует нешифрованный TCP/IP. Весь трафик открыт. Хотя тот же Oracle по моим сведениям поддерживает в своем драйвере возможность шифрования. |
| Автор: SmaLL 25.7.2005, 16:33 |
| СдаЁтся мне что Рассада будет писать тотже JDBC драйвер только, например, с поддержкой шифрования. |
| Автор: AntonSaburov 25.7.2005, 16:44 |
| Так надо предварительно посмотреть, может это в драйверах уже есть. Хотя если надо для универсальности, тогда надо делать промежуточный слой для шифрования. Или организовать VPN внутри подсети. |
| Автор: Итальянец 25.7.2005, 22:58 |
| Я так понимаю у Рассада задача написать мост альтернативный JDBC? Или ему нужно просто обеспечить более высокую надежность? Вообще-то я сомневаюсь, что с мостом у него что-то получится, по-моему гораздо легче и экономнее обеспечить надежность. |
| Автор: Stampede 25.7.2005, 23:37 | ||
Я понимаю, что требование идет откуда-то сверху и, возможно, из кругов не сильно компетентных, но все же можно поподробнее, что именно подразумевается под "должной надежностью"? Просто слово достаточно многозначное, хотелось бы уточнить. В любом случае, требование реализовать собственный метод доступа к БД (да еще с условием переносимости между СУБД) есть очевидная и дорогостоящая глупость. Потому что выйдет в итоге тот же JDBC - просто в силу природы взаимодействия ДБ-серверов с SQL-клиентами. Ибо цикл выполнения SQL команды - он и в африке цикл, безотносительно к тому, как называется библиотека доступа: ODBC, JDBC или Vasya Pupkin's Data Access Library |
| Автор: Рассада 26.7.2005, 09:52 | ||||||
SmaLL, мне самому так сдается  .
1. Точно. 2. Возможный вариант..? Stampede, под недостаточной надежностью понимается то, о чем сказал AntonSaburov(как я понял  ):
|
| Автор: LSD 26.7.2005, 10:17 |
| Рассада если тебе надо шифровать трафик, то используй VPN как советовал AntonSaburov, тот же OCI не позволит сам по себе передавать шифрованные данные, только совместно с Oracle Advanced Security. Да и другие низкоуровневые интерфейсы тоже врядли смогут работать с шифрованными данными, если это в них не заложенно изначально. А если уж никак VPN нельзя, то придется на сервере где стоит СУБД, запускать некого твоего агента, который будет соединяться с БД от имени клиента и передавать ему данные по шифрованному каналу. |
| Автор: hatsumeika 2.8.2005, 20:49 |
| Если задача решается шифрованием, можно шифровать данные записываемые в БД. Тут конечно будет полно побочных эффектов, например перестанет работать сравнение >, <. Но останется ==, != Еще можно исключить трафик между приложением и БД по сети посредством сервера приложений, живущего на одном компе с БД. Объекты передаваемые между клиентом и сервером можно шифровать при сериализации. |