Форум MySQL

нашли мы хостинг, где дают и MYSQL и FB/IB. я даже уже залила туда сайт. но базу FB подключить
не удается. вернее, не получается именно мою базу подключить. я думала, что по аналогии с
локальным хостом просто кидаешь файл с базой в папку на сервере, прописываешь путь к ней в
конфигурационном файле и вперед - можно работать с базой. но не тут-то было. хостер сказал:
==========================================================
Напрямую с папкой на виртуальном хостинге Вы работать не сможете.
Делайте экспорт/импорт csv.
==========================================================

какой облом! я-то думала, как хорошо, что у FB все в одном файле - и структура и данные, удобно
обновлять будет. а тут мне предлагают опять экспорт/импорт через csv. так я тогда и в MySQL
могу импорт сделать и не мучаться с FB...

а сейчас даже у этого хостера ничего не спросить - не открывается ни наш временный IP, ни
панель управления, ни сайт хостера... и на письма хостер не отвечает. :(

кто работал с FB и PHP? как вы заливаете базу на сервер?

думаете, лучше будет использовать SQLite?
а как тогда переносить данные из FireBird?

Извините, может я не догоняю чего... а почему сам MySQL отвергнут? Дорого чтоли?

у заказчиков в настольном приложении используется FireBird. данные очень объемные. они
сканируют разные документы, потом заносят их в базу с разными ключевыми словами, а
потом ищут. вот они и захотели какую-то часть этой базы опубликовать в интернете на
сайте. и сделать там тоже небольшой поиск. но т.к. база у них постоянно пополняется, они
хотят иметь возможность самим ее обновлять на сервере. у меня сайт использует MySQL,
управляется через админский модуль. я написала скрипт поиска по базе FireBird на PHP. а
вот саму базу приходится обновлять через экспорт/импорт csv. это неудобно. если бы у
меня сразу был csv, я бы не заморачивалась с FB, а делала бы все в MySQL. я могла бы и
скрипт импорта написать. а если вдруг клиенты изменят структуру таблиц? придется пере
писывать скрипты. хотя не исключено, что их и так бы пришлось переделывать. я совсем
запуталась. а! еще! MySQL не работает с датами меньше 01/01/1970, а у них старинные
документы и поиск по датам тоже очень важен...

>а если вдруг клиенты изменят структуру таблиц?

Значит нужно оговорить этот момент в контракте.

>MySQL не работает с датами меньше 01/01/1970, а у них старинные
документы и поиск по датам тоже очень важен...

MySQL работает с такими датами, если хранить их в полях типа DATETIME
Диапазон представления от 1000-01-01 00:00:00 до 9999-12-31 23:59:59
Наврядли у Ваших клентов документы старее 10 века....

Можно также хранить данные в чистом timestamp (в виде int или bigint), но преобразование придется выполнять самостоятельно.

16 и 11 век точно есть... наши клиенты - попы из монастыря на Афоне

Тогда проблема с датами куда круче, чем представляется на первый взгляд.
То есть если нужно всего лишь поиск вести - не страшно. Тогда её можно просто хранить в выравненном виде с фиксированной длиной (YYYYMMDDHHMMSS) в столбике CHAR(14).

А вот если требуется интервалы считать - вот тогда пиндык.
В районе 16 века пошел активный процесс отторгания юлианского календаря, и коллеги Ваших заказчиков в тех окресностях даты считали, как придется. А в некоторых странах (в России, к примеру) и до сих пор, пожалуй, так считают...
Как минимум, MySQL настоятельно предостерегает пользоваться проблемно-чувствительными функциями ( FROM_DAYS() , TO_DAYS() ) для работы с датами ранее 1582 года.