Здравствуйте, xBlackCat, Вы писали:
BC>Обращаюсь к людям, скачавших/пользующихся Rojac.
А в каком формате хранится БД и можно ли подключить/сконвертировать уже существующий .mdb-файл от Януса? Вику бегло просмотрел, но этой информации не нашел.
Здравствуйте, SchweinDeBurg.
Вы писали:
SDB> Здравствуйте, xBlackCat, Вы писали: SDB> BC>Обращаюсь к людям, скачавших/пользующихся Rojac. SDB> А в каком формате хранится БД и можно ли подключить/сконвертировать уже существующий .mdb-файл от Януса? Вику бегло просмотрел, но этой информации не нашел.
К сожалению, нельзя сделать импорт из Януса (спасибо за мысль подкинутую )
Сейчас существует два "движка" хранения: встраиваемая база H2SQL и внешняя MySQL. При запуске программы можно выбрать параметры. Потенциально можно использовать любую SQL БД, для которой есть JDBC драйвер (кстати, ищу знатоков для портирования на MSSQL и PostgreSQL. Сам не успеваю таким занятся).
Между базами Rojac можно делать импорт данных.
Здравствуйте, xBlackCat, Вы писали:
BC>К сожалению, нельзя сделать импорт из Януса (спасибо за мысль подкинутую )
Не за что, если это реализовать, то было бы здорово — 2 гига информации терять не хочется, а на MSSQL я что-то не созрел пока.
BC>Сейчас существует два "движка" хранения: встраиваемая база H2SQL и внешняя MySQL.
Насколько я понимаю, "ручной" импорт в MySQL не должен быть совсем уж непосильной задачей, если, конечно, структура БД не слишком отличается. За Джаву не скажу, а вот ODBC я в свое время использовал довольно плотно (правда не знаю, есть ли провайдер для MySQL).
Здравствуйте, SchweinDeBurg.
Вы писали:
SDB> Здравствуйте, xBlackCat, Вы писали: SDB> BC>К сожалению, нельзя сделать импорт из Януса (спасибо за мысль подкинутую ) SDB> Не за что, если это реализовать, то было бы здорово — 2 гига информации терять не хочется, а на MSSQL я что-то не созрел пока. SDB> BC>Сейчас существует два "движка" хранения: встраиваемая база H2SQL и внешняя MySQL. SDB> Насколько я понимаю, "ручной" импорт в MySQL не должен быть совсем уж непосильной задачей, если, конечно, структура БД не слишком отличается. За Джаву не скажу, а вот ODBC я в свое время использовал довольно плотно (правда не знаю, есть ли провайдер для MySQL).
Для ручного импорта нужно знать структуру БД. Думаю покопаться во внутренностях Janus'а на досуге на счёт базы. Если у кого есть уже готовый DDL для создания БД в Янусе — буду рад принять в дар
На счёт импорта из mdb — тут проблемка небольшая: прямые JDBC к MS Access базам платные. Прийдётся сделать JDBC-ODBC мост. Я ещё не придумал, как это красивее сделать с точки зрения юзера.
Здравствуйте, xBlackCat, Вы писали:
BC>Для ручного импорта нужно знать структуру БД. Думаю покопаться во внутренностях Janus'а на досуге на счёт базы. Если у кого есть уже готовый DDL для создания БД в Янусе — буду рад принять в дар
Там структура БД довольно часто менялась даже в пределах одной "мажорной" версии, насколько я помню, и в состав Януса входит так называемый реструктуризатор, который эту ситуацию обрабатывает (по крайней мере — должен, у меня падал).
BC>На счёт импорта из mdb — тут проблемка небольшая: прямые JDBC к MS Access базам платные.
Здравствуйте, SchweinDeBurg.
Вы писали:
SDB> BC>На счёт импорта из mdb — тут проблемка небольшая: прямые JDBC к MS Access базам платные. SDB> Жесть, ничего не скажешь!
Здравствуйте, xBlackCat, Вы писали:
BC>Потенциально можно использовать любую SQL БД, для которой есть JDBC драйвер (кстати, ищу знатоков для портирования на MSSQL и PostgreSQL. Сам не успеваю таким занятся).
А зачем это вообще делать? Не проще ли определиться с "идеальным" встраиваемым хранилищем, и не парить себе мозг доступным зоопарком? Кому какое дело, что там шуршит под капотом FB, SQLite или MSSQL
Здравствуйте, xBlackCat, Вы писали:
BC>Здравствуйте, SchweinDeBurg. BC>Вы писали:
SDB>> Здравствуйте, xBlackCat, Вы писали: SDB>> BC>К сожалению, нельзя сделать импорт из Януса (спасибо за мысль подкинутую ) SDB>> Не за что, если это реализовать, то было бы здорово — 2 гига информации терять не хочется, а на MSSQL я что-то не созрел пока. SDB>> BC>Сейчас существует два "движка" хранения: встраиваемая база H2SQL и внешняя MySQL. SDB>> Насколько я понимаю, "ручной" импорт в MySQL не должен быть совсем уж непосильной задачей, если, конечно, структура БД не слишком отличается. За Джаву не скажу, а вот ODBC я в свое время использовал довольно плотно (правда не знаю, есть ли провайдер для MySQL).
BC>Для ручного импорта нужно знать структуру БД. Думаю покопаться во внутренностях Janus'а на досуге на счёт базы. Если у кого есть уже готовый DDL для создания БД в Янусе — буду рад принять в дар
Скрипт есть в ресурсах и он вроде распаковывается автоматом. Лави
Здравствуйте, hattab.
Вы писали:
H> Здравствуйте, xBlackCat, Вы писали: H> BC>Потенциально можно использовать любую SQL БД, для которой есть JDBC драйвер (кстати, ищу знатоков для портирования на MSSQL и PostgreSQL. Сам не успеваю таким занятся). H> А зачем это вообще делать? Не проще ли определиться с "идеальным" встраиваемым хранилищем, и не парить себе мозг доступным зоопарком? Кому какое дело, что там шуршит под капотом FB, SQLite или MSSQL
К сожалению, встраиваемые СУБД не дают приемлемого качества/скорости. Тот же H2SQL забирает на себя существенную часть кучи при работе с БД, что иногла приводит к OOM exception на установленном по-умолчаниб размере кучи в 64Мб.
Здравствуйте, xBlackCat, Вы писали:
BC> H> А зачем это вообще делать? Не проще ли определиться с "идеальным" встраиваемым хранилищем, и не парить себе мозг доступным зоопарком? Кому какое дело, что там шуршит под капотом FB, SQLite или MSSQL
BC> К сожалению, встраиваемые СУБД не дают приемлемого качества/скорости. Тот же H2SQL забирает на себя существенную часть кучи при работе с БД, что иногла приводит к OOM exception на установленном по-умолчаниб размере кучи в 64Мб.
Ну ладно, H2SQL тебя не устраивает. Почему не взять SQLite или Firebird Embedded? Обе кроссплатформенные (у тебя вроде кто-то интересовался работой под линуксом), обе шустренькие (Avalon использует SQLite, и вполне себе неплохо справляется на базе в 1.2Gb), FBE так и вообще ураган
H> Ну ладно, H2SQL тебя не устраивает. Почему не взять SQLite или Firebird Embedded? Обе кроссплатформенные (у тебя вроде кто-то интересовался работой под линуксом), обе шустренькие (Avalon использует SQLite, и вполне себе неплохо справляется на базе в 1.2Gb), FBE так и вообще ураган
SQLite был одним из первых претендентов на разработку.
Все их преимущество съедается в JNI — в результате SQLite тормозил сильнее SmallSQL (а он ещё тормоз был).
Здравствуйте, xBlackCat, Вы писали:
BC> H> Ну ладно, H2SQL тебя не устраивает. Почему не взять SQLite или Firebird Embedded? Обе кроссплатформенные (у тебя вроде кто-то интересовался работой под линуксом), обе шустренькие (Avalon использует SQLite, и вполне себе неплохо справляется на базе в 1.2Gb), FBE так и вообще ураган
BC> SQLite был одним из первых претендентов на разработку. BC> Все их преимущество съедается в JNI — в результате SQLite тормозил сильнее SmallSQL (а он ещё тормоз был).
То есть вообще ничего приличного встроенного использовать не получилось, или как? Но ведь и с внешними БД взаимодействие осуществляется через прослойку Ну а FBE вообще собирается из того же кода, что и его standalone версия, там разницу можно почувствовать, разве что на многопоточном доступе (более того, встроенной версии не требуется межпроцессное взаимодействие).
Здравствуйте, hattab, Вы писали:
H>Ну ладно, H2SQL тебя не устраивает. Почему не взять SQLite
Какие то странные проблемы с строковыми блобами и периодические тормоза на запросе тем форума. Транзакции номинальны, что приводит к проблемам при многопоточном доступе. Это я про sqlite в янусе.
H> или Firebird Embedded
Странный SQL, много проблем совместимости, посредственный перформанс.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, hattab.
Вы писали:
H> То есть вообще ничего приличного встроенного использовать не получилось, или как? Но ведь и с внешними БД взаимодействие осуществляется через прослойку Ну а FBE вообще собирается из того же кода, что и его standalone версия, там разницу можно почувствовать, разве что на многопоточном доступе (более того, встроенной версии не требуется межпроцессное взаимодействие).
С внешними БД работа идёт через сокеты.
SQLite силён обновлениями в транзакциях: открыл коннекшн, начал транзакцию, сделал 1000х запросов, закоммитил. Тогда он быстрый. А в моём случае не получается держать открытый коннекшн долго — параллельность работы ломается.
К примеру, если я на Н2 в базу вставляю 1000 сообщений, то они заполняюся за 10 сек. В SQLite этот же механизм вставлял их более 15 минут (точные цифры не помню, но порядок был именно такой). А переделывать структуру приложения только ради SQLite не хотелось.
Он меня полностью устраивает Только если говоришь в форуме с 10К постами и больше "пометить все, как прочитанные", может закончится память на куче в 64Мб.
Здравствуйте, xBlackCat, Вы писали:
BC>Он меня полностью устраивает Только если говоришь в форуме с 10К постами и больше "пометить все, как прочитанные", может закончится память на куче в 64Мб.
А зачем ограничивать кучу таким смешным значением?
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK.
Вы писали:
AVK> Здравствуйте, xBlackCat, Вы писали: AVK> BC>Он меня полностью устраивает Только если говоришь в форуме с 10К постами и больше "пометить все, как прочитанные", может закончится память на куче в 64Мб. AVK> А зачем ограничивать кучу таким смешным значением?
Ну хотя бы из-за того, что при такой куче JVM уже ест около 200Мб в памяти (на х64 системе). Ну и просто дополнительный стимул не тратить зря память
При внешней БД этого размера кучи более чем достаточно.
Здравствуйте, AndrewVK, Вы писали:
AVK> H> или Firebird Embedded
AVK> Странный SQL
Чего странного в SQL-92 + части SQL-99 + некоторых расширениях? До FB активно работал с MSSQL 6.5 — 2000, при переходе на FB проблем с SQL не испытал
AVK> много проблем совместимости
Любые проблемы совместимости файлов БД решаются через backup/restore. Несовместимостей между версиями сервера с 1.5 по 2.5 не обнаружено (использую тонкую оберточку над API — UIB)
AVK> посредственный перформанс
Оракулу сольет конечно, но потребности янусов перекроет многократно.
)
