Подскажите компоненты для реализации проекта

[MaximK]

Появилась необходимость написать клиент-сервер приложение. Никогда подобным не занимался. Вот стою перед выбором: на основании чего или какой связки писать приложение.

Задача: показывать он-лайн заявки на выполнение работ (время, готовность к выезду, переносы, отмены и т.п.). Необходимо создание нескольких типов клиента: монитор(просто просмотр текущих заявок), редактор в диспетчерской (добавление, редактирование). При этом несколько клиентов должны работать одновременно.

Серверная часть (пока на Windows):
* Работа с базой данных по добавлению, редактированию и выборке данных.
* Архивирование старых данных
Думаю надо копать в сторону MySQL, хотя раньше использовал SQLite

Клиент (монитор):
* Отображение текущих данных
Сначала думал делать на LNet, но вроде там нет многотопочности или у меня не получилось.

Клиент (диспетчер):
* Добавление, изменение заявок

Это для начала. В дальнейшем если это получится, то:
* возможность просматривать заявки через интернет (web-client)
Наверное PHP+MySQL или CGI+SQLite
* клиент для сдачи документов (актов, подписанных заявок) в электронный архив.
* Серверная часть для FreeBSD


В конечном результате хочу получить следующее:

Заказчик через интернет (web-клиент) подает заявку на выполнение работ. Она записывается в базу на сервере. Либо диспетчер приняв заявку по телефону заносит ее в базу (клиент "Диспетчер"). Далее диспетчер увидев заявку назначает исполнителя. Аппаратурный участок готовит приборы для этой заявки соответственно типу планируемых работ(клиент "Монитор"). Склад, готовит необходимые материалы, заранее формирует списки недостающих материалов(клиент "Монитор"). Отдел обработки готовит исходные данные для выезда по заявке. И все это время список поступивших, подтвержденных и выполняемых заявок отображается на мониторе в холле предприятия, где могут это увидеть исполнители работ(клиент "Монитор").
После выполнения работ и возвращения на базу, данные полученные во время выполнения работ также записываются в базу(клиент "Сдача материала"). Объем файлов от 10Мб - 150 Мб. Отдел обработки обрабатывает их получив из базы и сохраняет результаты обработки так же в базе. Объем файлов от 1Мб - 10 Мб. Заказчик (их может быть одновременно до 10 чел.) через интернет скачивает необходимые результаты выполненных работ.

Таким образом одновременно будет работать:
Web-клиент (до 10 подключений. Заказчики нетерпеливые будут проверять готовность часто, исполнители находящиеся в разных городах)
клиент "Монитор" (минимум 4 клиента)
клиент "Диспетчер" (1 клиент)

Объем данных: Сданный и обработанный материал за год около 60Гб. Но это файлы. В базе думаю хранить только пути к файлам.


Вот такие Наполеоновские планы. Подскажите в какую сторону копать и на каких компонентах это можно реализовать, чтобы потом не переделывать из-за того, что у компонента не хватает возможностей.

[vada]

MySQL - {PHP | JAVA} - {Apach | Tomcat} => счастье

[svk12]

Firebird + ZeosDbo||SQLDb||FbExpress;

[Ism]

Кроме mysql мало, что подойдет, эта штука работает на всех платформах и легко настраивается, mysql лучше всего работает в web
MySql может работать в embedded режиме, как sqlite

Есть еще postgress, но он тяжелый

[svk12]

ОгнеПтиц-то чем нехорош?

[Ism]

В многопользовательском режиме он не очень, да и производительность не лучшая.
Если база большая это не лучший выбор
И как вы к нему прикрутите вебинтерфейс ?

[GrayEddy]

AMP рулит. Apache + MySQL + PHP.

И как вы к нему прикрутите вебинтерфейс ?

Что за проблемы у PHP достучаться до базы Firebird?

[svk12]

В многопользовательском режиме он не очень, да и производительность не лучшая.

Имею с ним дело с 1998г., с IB-4, и как-то и с первым проблем не было, и второго хватало.

И как вы к нему прикрутите вебинтерфейс ?

Сам я этим не занимался(не было нужно), но был свидетелем, как человек без особого напряга подключался через Apache+PHP.

Apache + MySQL + PHP

Всё это хорошо, но, пардоньте, где же здесь FPC и Lasarus?
Может быть, стоит просто дать ТСу ссылку на какой-нибудь PHP-форум?

[Ism]

Всё это хорошо, но, пардоньте, где же здесь FPC и Lasarus?

Есть много компонентов для Lazarus работающих с MySql

Кроме того есть cgi, насколько я знаю

Добавлено спустя 1 минуту 14 секунд:
http://jnanatal.blogspot.com/2011/01/cgi-lazarus.html

Добавлено спустя 1 минуту 6 секунд:
http://wiki.lazarus.freepascal.org/CGI_Web_Programming

[alexs]

В многопользовательском режиме он не очень, да и производительность не лучшая.

Вы тут полносью не правы...
Огнептиц за 10 лет моей эксплуатации зарекомендовал себя как одна из самых надёжных системы.
Фактически благодаря ему одна крупная система всё это время работает без сбоев.
500 пользователей одновременно - это наверное всёж показатель многопользовательской работы?
Мой выбор - для небольших системы - лучше FireBird ничего нет.
А MySQL - оставьте его в своей нише - он не вырос из веб приложений...
Если вам нужна крупная система, где действительно много пользователей - то после жарптицы следует PostgreSQL...
Тем более они очень похожи в синтаксисе...

[GrayEddy]

Мой выбор - для небольших системы - лучше FireBird ничего нет.
А MySQL - оставьте его в своей нише - он не вырос из веб приложений...

Не соглашусь.
По опыту - MySQL при простых запросах вчистую обыгрывает Firebird. В ряде случаев в несколько раз. Да и работает действительно шустро.
В инете (и в мире) - MySQL - стандарт-де факто.

Слабое место MySQL - при сложных запросах (типа вложенных) - тут Firebird берет вверх.

[alexs]

Что такое инет приложение - обычно магазин, или просто набор странц (яркий пример - медиа-вики).
Условия эксплуатации:
- Быстрое чтение
- Конкурирующих подключений минимум (обычно всё в пределах одного сервера работает, максимум - кластер из 2-5 вебсерверов), т.е. реальной многопользовательской работы нет
- у нет критичных к хранению данных - только небольшой объём оперативного архива
- план востановления системы обычно очень сильно завязан на то, что сервер находится в дата центре и сам является достаточно надёжным. Т.е. вся надёжность сервера расчитана на инфраструктуру вокруг него.
- нет "тяжёлых" статистических запросов

Теперь ральный клиент-сервер
- Скорость записи также важна как и чтения (объём создаваемых докуметов в разы больше)
- Условия эксплатации далеки от идеальных - сервер может быть как и надёжным кластером в дата-центре, так и обычной персоналкой бухгалтера без УПС
- В БД должны храниться данные о работе предприятия за несколько лет и эти данные критичны для всех. Утеря их недопустима.
- Время востановления должно быть минимальным и, желательно, сам процес востановления после сбоя оборудования должен быть прозрачным для всех.
- Одновременно работающих сотрудников явно >>10, и ещё всегда есть инициативные сотрудники, которые в разгар операционного дня хотят посмотреть статистику за 3-5 лет, динамику и т.д.
- Про транзакционную целостность тут даже не обсуждается - это первое условие выбора сервера (грязные данные просто не допустимы)

Вот исходя из этого я говорю о области применения каждого сервера.
Хотя по функционалу, предоставляемому программисту, они приблизительно равны.
PS
Ради справедливости надо отметить, что в MySQL сейчас с транзакциями и тригерами вроде всё уже по взрослому...

[AlexVinS]

Без "Серверная часть для FreeBSD" и "возможность просматривать заявки через интернет (web-client)" проще реализовать на 1С. С такой перспективой и/или при большом количестве пользователей уже:
*1С фтопку.
*БД firebird - для базы в несколько гигабайт его хватит (но сайт на LAMP|FAMP для сайта готовые решения с MySQL могут быть удобнее, но постарайтесь не подключать слой данных - который на firebird - напрямую к сайту из соображений безопасности: сайт вероятно вскроют но вот кроме просмотра заявок ничего не должно оттуда быть доступно в принципе).
* компоненты доступа - любые - заранее не угадаешь что подойдет лучше в данном конкретном случае, для начала возьмите стандартный SQLDB.
* для самой проги - TiOPF.

[Vadim]

Кину камень в огород MySQL. Скачал недавно последнюю версию 5.6.5, поставил, залил базы со старого сервера, запустил - и с ужасом обнаружил, что движок InnoDB там больше не поддерживается - все внешние ключи полетели в жо..., целостности данных больше нет, хотя база продолжает работать.
Так что имейте в виду, oracle жжот не по детски.

[Ism]

http://ru.wikipedia.org/wiki/MySQL

MySQL 5.5

Ветка MySQL 5.5 базируется на невыпущенной серии MySQL 5.4 и содержит ряд значительных улучшений, связанных с повышением масштабируемости и производительности, среди которых:
Использование по умолчанию движка InnoDB.
Поддержка полусинхронного (semi-synchronous) механизма репликации, основанного на патчах к InnoDB от компании Google.
Улучшение функций по партицированию данных. Расширенный синтаксис для разбиения больших таблиц на несколько частей, размещенных в * разных файловых системах (partitioning). Добавлены операции RANGE, LIST и метод оптимизации «partition pruning».
Новый механизм оптимизации вложенных запросов и JOIN операций.
Переработана система внутренних блокировок.
Интегрированы патчи Google с оптимизацией работы InnoDB на CPU с большим количеством ядер.

Добавлено спустя 1 минуту 49 секунд:
Это с вашим скриптом чтото не так

Добавлено спустя 4 минуты 23 секунды:
Да и на сайте нет 5.6.5, это что, бета ?

Добавлено спустя 38 минут 2 секунды:
Хотя после переустановки может не работать innodb , у меня вообще сервер не запустился , как написано тут

Plugin 'InnoDB' init function returned error.
Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
Unknown/unsupported storage engine: INNODB

http://forums.mysql.com/read.php?10,267434,267782
http://forums.mysql.com/read.php?22,297611,297611

Нужно удалить файлы ib_logfile в папке C:\ProgramData\MySQL\MySQL Server 5.5\data и перезапустить mysql сервер , он пересоздаст их с нужными параметрами и все будет работать