Fallout13, спасибо за развернутый отзыв и список предложений. На счет бета-теста будем иметь ввиду.
Смущает использование мускула для трендов. На сколько хватит его скорострельности, да и база будет расти очень быстро. Не мне вам рассказывать что в больших скадах для этого делают несколько по другому.
Хватит вполне для довольно больших проектов. В текущей версии скады используются собственные базы трендов, которые значительно уступают в скорости и пр. параметрах MySQL. MySQL сейчас показывает очень хорошие результаты при правильном использовании. Взять к примеру распространенную скаду WinCC, которая использует базу данных Microsoft SQL Server и показывает хорошее быстродействие, которого хватает в крупных промышленных системах. В ряде запросов MySQL показывает худшее быстродействие, но остается на хорошем уровне, это действительно так. Мы используем MySQL с InnoDB таблицами, которые поддерживают кластерные индексы, так же, как и WinCC с Microsoft SQL Server'ом, благодаря чему данные всегда структурированы сразу по двум полям (!) и выборки даже в огромных таблицах происходят очень быстро. Мы не раз убедились в этом в недавних тестах. К тому же здесь играет роль и то, как данные записываются в БД. Мы не сохраняем в базу чистые данные, ведь их может быть слишком много в больших проектах. Поэтому, прежде чем данные будут записаны в БД, они обрабатываются и оптимизируются, чтобы получить наименьший объем данных при записи в БД (разумеется без потери качества данных) и соответственно наименьший объем при хранении данных на жестком диске и при последующем считывании данных. И здесь есть огромный простор для оптимизаций. Поэтому сейчас мы уверены в скорости MySQL даже для больших проектов и не видим существенной разницы даже с Microsoft SQL Server'ом (после релиза второй версии добавим и его поддержку, а также, возможно PostgreSQL). Ещё одним немаловажным фактором в пользу MySQL выступает её бесплатность, а для нас важно сохранить максимально низкую цену.
Но Вы, как мы поняли, говорили о таких примерах, как например Trace Mode с их SIAD/SQL и заявленной производительностью записи более 640 тыс. изменений аналоговых параметров в секунду. Мы о такой производительности заявить не можем, но причина вовсе не в выбранной БД. Для того, чтобы достичь такой производительности нужно ещё сильнее оптимизировать данные трендов и запросы к БД ещё до записи в неё. Возможно мы займемся этим в будущем, но пока нам хватает текущей производительности.
Заранее хотелось бы узнать про ценовую политику и особенности лицензирования.
Об этом мы обязательно напишем подробнее, но ближе к релизу, чтобы не давать сейчас пустых обещаний. Точно можем сказать, что постараемся держать максимально низкую цену и предложим хорошие условия связанные с дальнейшим обновлением скады после покупки.
1. Хотелось бы на всплывающих окошках отображать список активных алярмов для конкретного мех-ма.
Пожалуйста, опишите этот пункт подробнее. Вы говорите о возможности показать окошко в котором будет находиться список аварий какого-то конкретного механизма за определенный промежуток времени?
Жизненно необходимы теги-указатели
И этот момент не до конца понятен. В новой версии будут виртуальные теги, в которые можно записать все что угодно, например значение другого тега, или сумму нескольких тегов, или какое-то значение посчитанное по какой-то формуле (на усмотрение пользователя). О таких тегах Вы говорите?
Хотелось бы увидеть поддержку актив-икс
Поддержки ActiveX не будет точно. Это нарушает все наши принципы используемые при разработке Simple-Scada, такие как максимальное упрощение, скорость отрисовки и загрузки компонентов, быстродействие компонентов и быстрая их обработка. Также ActiveX принесет с собой множество серьезных уязвимостей. Поэтому, после выхода Simple-Scada 2 с набором основных компонентов постараемся добавить другие важные компоненты, которые пригодятся пользователям.
Остальные пункты будут сделаны.
