Существет ли СУБД с файлами базы переносимыми между little и big endian платформами?

db2 ?

мускуль (MyISAM) и SQLite.

а ссылку можно?

я вот нашел в FAQ:

SQLite databases created on a little-endian architecture cannot be used on a big-endian machine and vice versa.

http://www.sambar.com/syshelp/sqlite/faq.htm

а экспорт-импорт баз не катит?

http://www.mysql.ru/docs/man/MyISAM.html

Странно. А на wiki sqlite они сравнивают себя с dbstar и фукают на них что они little-endian only.

да мне просто нужно доказать людям, что такой фичи ни у кого в серьезной СУБД нет и делать ее не стоит. Ибо получившийся код будет не поддерживаем в принципе, даже если удасться отладить

Вот про sqlite: http://sb-news.net/sqlite.php?page=6#q6

понятно. спасибо

Тут товарисчи подсказывают что оракл тоже владеет этим даром.

Кажется в оракле 10 есть специальный костыль для переноса данных. Просто скопировать базу на флешку и запустить на платформе с другим порядком бай не получится http://www.dba-oracle.com/art_dbazine_ault_cross_plat.htm. Кстати в MyISam я не понял переносима вся база или только фалй с таблицами.

> да мне просто нужно доказать людям, что такой фичи ни у кого в серьезной СУБД нет и делать ее не стоит. Ибо получившийся код будет не поддерживаем в принципе, даже если удасться отладить

А что такого-то? Как я понимаю речь идет о формате ондискового стораджа. Практически все форматы бинарных файлов не зависят от того, какая машина, bigendian или little. И ничего, живут. Файловые системы похоже тоже endianness-независимые.

ps. а между 32 и 64 битными у вас тоже совместимости не будет?

Речь идет о рабочих файлах базы данных. Это далеко не байтовый бинарный формат.

> ps. а между 32 и 64 битными у вас тоже совместимости не будет? А с этим-то какие проблеммы?

> Речь идет о рабочих файлах базы данных. Это далеко не байтовый бинарный формат.

>> а между 32 и 64 битными у вас тоже совместимости не будет?

>А с этим-то какие проблеммы?

Ну, как я понимаю, желание не иметь big/litte-endian совместимости происходит от желания делать вещи вида

struct some_data_struct { int something; ucs2_char something_else; ... }

и потом писать-читать такие структуры на диск без перекодировок. Боюсь, что при этом окажется что вы зависите еще от выравнивания (некотрые машины не дают иметь n-байтные типы по адресам, не делящимся на n) и скорее всего от sizeof всяких типов тоже.

AFAIK работают оба подхода - первый в postgresql, где базу даже между двумя x86 системами таскать нельзя, второй в mysql, где наоборот в пределах одной версии все файлы работают на всех системах.

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

> Речь идет о рабочих файлах базы данных. Это далеко не байтовый бинарный формат.

Не поделитесь, чего там такого далекого?

Бинарные форматы конечных файлов затачиваются на мультибайтное представление. Реализация СБУД с которой я имею дело не имеет архитектурной поддержки этой фичи. Многие вещи серализуются как бинарные блобы(кстати описнных проблемм с выравниванием там нет. Так что она без проблемм собирается например под arm). Запись в серилизуемые буферы раскинута во всему исходному коду и практически невозможно гарантировать полноту правок(да и не всегда очевидно в каком месте делать переворот). Проблемма не в принципиальной реализуемости, а во времени и целесообразности этого дела. Гораздо проще решить проблемму на прикладном уровне.