Vadim писал(а):Кину камень в огород MySQL. Скачал недавно последнюю версию 5.6.5, поставил, залил базы со старого сервера, запустил - и с ужасом обнаружил, что движок InnoDB там больше не поддерживается - все внешние ключи полетели в жо..., целостности данных больше нет, хотя база продолжает работать. Так что имейте в виду, oracle жжот не по детски.
А вы скачали откуда-то или с языками у вас непорядок. 5.6.5 - сообщение "Archives » MySQL Database Server 5.6 » 5.6.5 - Please note that these are old versions and may include bugs that are fixed in more recent versions!"
Ism писал(а):Нужно удалить файлы ib_logfile в папке C:\ProgramData\MySQL\MySQL Server 5.5\data и перезапустить mysql сервер , он пересоздаст их с нужными параметрами и все будет работать
Спасибо, я попробую. Но, согласитесь, когда свежеустановленная MySQL выкидывает такие фортели - это уже говорит не в её пользу.
Спасибо всем за советы. Наверное попробую с FireBird.
Есть еще один маленький вопросик. Если я правильно представляю себе работу приложения, то она будет следующая: Клиент обращается к приложению-сервер(по IP и порту). Сервер обращается к базе данных, получает ответ от базы и отправляет клиенту.
Да примерно так. Кстати еще вопрос на базе чего организовывать взаимодействие клиент-сервер. Что-то под лазарус я сходу ничего и не припомню хорошего. (Можно конечно свой велосипед на базе любого универсального TCP сервера -lnet, synapse итп, но может быть достаточно кропотливо).
svk12 писал(а):А двухзвенки не хватит? Приложение-клиент - сервер СУБД?
Может быть и хватит. Вот только я подумал, если скажем изменится структура базы или запросов, придется корректировать все типы клиентов, а если запрос будут обрабатывать программа-сервер, то в коррекции будет нуждаться только она.
MaximK Где-то в недрах sourceforge.net лежит DBNetProcessor - как раз то самое промежуточное звено между клиентом и SQL-сервером. Сетевая часть на Synapse, db - на ZEOS. В комплекте есть пример для SQLite.
MaximK писал(а):Вот только я подумал, если скажем изменится структура базы или запросов, придется корректировать все типы клиентов, а если запрос будут обрабатывать программа-сервер, то в коррекции будет нуждаться только она.
О!!! Это что-то новое... Как вы это себе представляете? Как может клиентский интерфейс быть полностью не зависимым от структуры данных? WEB?
Ну на данный момент я представляю это так: Клиент просит у сервера заявку №37. Сервер соединяется с таблицей БД и делает запрос, получает ответ и формирует свой ответ клиенту. Т.О. если к примеру я изменю название таблицы/поля/имя БД, то поменяю код сервера и все. На получение клиентом ответа, это никак не скажется. Или же я скажем сначала буду записывать заказчика в общую таблицу, а потом вынесу в отдельную, чтоб добавить дополнительные данные о нем, а вместо имени заказчика в основной таблице использовать его номер, то опять же изменив только сервер, клиент останется работоспособным. Как то так. Может быть когда я начну реализовывать это, мои взгляды и изменятся. Не знаю. К сожалению нет опыта в подобных проектах и вообще сервер-клиентах.
Эммм... При таком подходе клиент точно не будет работать. Предположим - вы добавили/изменили колонку в таблице. И как клиентская программа узнает об изменениях? Можно, конечно, проверять таблицы/поля и строя формы на лету с учетом изменений. Но это геморройно. Как вариант - в базе есть таблица с номером версии базы. При открытии клиент сравнивает свою версию с версией базы. При несовпадении - обновление клиента (exe + dll + файлы/шаблоны отчетов). Детали обновления - за вами.
В случае веб-решения - все предельно просто. Вносятся правки в базу и в код страницы/сайта на сервере. Клиент даже не увидит изменений, все скрыто от него. Есть туча PHP-фреймворков, которые позволяют работать в диапазоне от маленьких до больших проектов с сильной нагрузкой.
Добавлено спустя 12 минут 46 секунд: Опять же, надо смотреть условия проекта. - сколько клиентов будет бомбить базу? - как часто будет идти чтение/запись? В минуту, час? Насколько будет велик объем вводимых данных, каких размеров может достигнуть база в течение месяца/года (аппроксимируем). - выбор СУБД, структура базы. - ОС клиентов и базы.
Заказчик через интернет (web-клиент) подает заявку на выполнение работ. Она записывается в базу на сервере. Либо диспетчер приняв заявку по телефону заносит ее в базу (клиент "Диспетчер"). Далее диспетчер увидев заявку назначает исполнителя. Аппаратурный участок готовит приборы для этой заявки соответственно типу планируемых работ(клиент "Монитор"). Склад, готовит необходимые материалы, заранее формирует списки недостающих материалов(клиент "Монитор"). Отдел обработки готовит исходные данные для выезда по заявке. И все это время список поступивших, подтвержденных и выполняемых заявок отображается на мониторе в холле предприятия, где могут это увидеть исполнители работ(клиент "Монитор"). После выполнения работ и возвращения на базу, данные полученные во время выполнения работ также записываются в базу(клиент "Сдача материала"). Объем файлов от 10Мб - 150 Мб. Отдел обработки обрабатывает их получив из базы и сохраняет результаты обработки так же в базе. Объем файлов от 1Мб - 10 Мб. Заказчик (их может быть одновременно до 10 чел.) через интернет скачивает необходимые результаты выполненных работ.
Таким образом одновременно будет работать: Web-клиент (до 10 подключений. Заказчики нетерпеливые будут проверять готовность часто, исполнители находящиеся в разных городах) клиент "Монитор" (минимум 4 клиента) клиент "Диспетчер" (1 клиент)
Объем данных: Сданный и обработанный материал за год около 60Гб. Но это файлы. В базе думаю хранить только пути к файлам.
для такого конечного результат надо как минимум нанять штат программистов человек в 5 и пахать несколько месяцев для создания только пробной версии. а дальше уже пилить точить.
Скачал недавно последнюю версию 5.6.5, поставил, залил базы со старого сервера, запустил - и с ужасом обнаружил, что движок InnoDB там больше не поддерживается - все внешние ключи полетели в жо..., целостности данных больше нет, хотя база продолжает работать.
