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

[MaximK]

для такого конечного результат надо как минимум нанять штат программистов человек в 5 и пахать несколько месяцев для создания только пробной версии. а дальше уже пилить точить.

Ну штат нанять никто не даст. А вот по срокам ограничения пока нет =)

Видео?

нет.

У нас есть сервер под FreeBSD. Вот только сисадмин ни как не даст ему ума. Очень часто не работает и неделями стоит не запущенный.

[AlexVinS]

Вот только я подумал, если скажем изменится структура базы или запросов, придется корректировать все типы клиентов, а если запрос будут обрабатывать программа-сервер, то в коррекции будет нуждаться только она.

О!!!
Это что-то новое...
Как вы это себе представляете?
Как может клиентский интерфейс быть полностью не зависимым от структуры данных?
WEB?

Очень даже может. Пример - 1С. Суть в том что интерфейс полностью динамический.

[alexs]

Очень даже может. Пример - 1С. Суть в том что интерфейс полностью динамический.

Всё равно где-то есть механизм, который ретранслирует вашу стрктуру БД в интерфейс пользователя. И при изменеии стркутуры БД надо будет менять этот механизм.
И не важно - это либо "толстый клиент" - классическая двухзвенка (надо менять программу у оператора) или трёхзвенка с веб мородой - надо менять ПО на сервере приложений.

[Ism]

Очень даже может. Пример - 1С. Суть в том что интерфейс полностью динамический.

1C - пятое колесо в телеге, его можно заменить Mysql(или любая база)+Lazarus+ Система отчетов
Сила 1С в готовых конфигурациях, но в большинстве случаев это не нужно.

Стандартизуйте названия объектов внутри базы и будет вам 1C

[AlexVinS]

Очень даже может. Пример - 1С. Суть в том что интерфейс полностью динамический.

Всё равно где-то есть механизм, который ретранслирует вашу стрктуру БД в интерфейс пользователя. И при изменеии стркутуры БД надо будет менять этот механизм.
И не важно - это либо "толстый клиент" - классическая двухзвенка (надо менять программу у оператора) или трёхзвенка с веб мородой - надо менять ПО на сервере приложений.

1)Вопрос был только про клиента ваще-то. 2) механизм то как раз менять не надо, если есть достаточное количество метаданных. Только изменение формата самих метаданных потребует изменение еще и механизма. 3) кстати при двухзвенке с логикой на ХП, можно и толстого клиента сделать независисмым от структуры БД (прикладной ее части, метаданные там же могут лежать)

Добавлено спустя 6 минут 47 секунд:

Очень даже может. Пример - 1С. Суть в том что интерфейс полностью динамический.

1C - пятое колесо в телеге, его можно заменить Mysql(или любая база)+Lazarus+ Система отчетов
Сила 1С в готовых конфигурациях, но в большинстве случаев это не нужно.

Стандартизуйте названия объектов внутри базы и будет вам 1C

С нуля писать гораздо в 1С проще чем (любая база)+Lazarus+ Система отчетов. (ну нету ни под лазарус ни под дельфи аналогов СКД и управляемых форм.) Готовые конфиги меня мало интересуют.

[alexey38]

При выборе платформы часто нужно рассматривать крайние варианты.
1-й вопрос, нет ли в предполагаемой БД персональных (см. закон о персональных данных) или конфиденциальных данных? Если что-то из этого есть, то это сильно ограничивает выбор средств. Банальный закон о персональных данных сделал не легитимными целую тучу имеющихся решений на разных системах программирования.

2-й вопрос в техобслуживании и требованиям к надежности системы. Что страшнее время простоя или утеря данных? Бывают ситуации, когда сервак стоит на объекте в тундре (в лесу, в степи, в горах), и сисадмин принципиально не желает жить в тех местах (в дали от людей). Время доставки сисадмина из города до объекта несколько часов или несколько дней. В таких условиях делаются решения, которые обслуживаются людьми не являющимися сисадминами.

3-й вопрос в требованиях к быстродействию. Сколько самих заявок может быть? Сколько в день? Как быстро нужно реагировать? Скорее всего у Вас вообще отсутствуют требования к быстродействию, т.е. любое решение будет быстрым.
Нужно предугадать возможные хотелки. В вашей задаче при реализации заявок для Вашей организации могут быть некие ресурсоемкие операции. Например, большая стоимость транспортировки оборудования. Или риск утери оборудования при транспортировке. Или еще что-то в этом роде. Тогда помимо сугубо информационных функций могут возникать всякие там оптимизационные решения. Типа того, что конкретному клиенту будет дешевле обслуживаться в конкретное время и т.п. Задача начинает разрастаться в бок, возникает взаимодействие со смежными системами: бухгалтерская, транспортная (логистическая) и т.п. В итоге конечное ТЗ будет совсем не похоже на первоначальное ТЗ. На выбор средств - это очень сильно влияет.

[Brainenjii]

я бы, разумеется, предложил сделать на viewtopic.php?f=10&t=8157 и viewtopic.php?f=10&t=8075 ^_^

[Ism]

Очень даже может. Пример - 1С. Суть в том что интерфейс полностью динамический.

1C - пятое колесо в телеге, его можно заменить Mysql(или любая база)+Lazarus+ Система отчетов
Сила 1С в готовых конфигурациях, но в большинстве случаев это не нужно.

Стандартизуйте названия объектов внутри базы и будет вам 1C

С нуля писать гораздо в 1С проще чем (любая база)+Lazarus+ Система отчетов. (ну нету ни под лазарус ни под дельфи аналогов СКД и управляемых форм.) Готовые конфиги меня мало интересуют.

Зато надежность , гибкость, и скорость гораздо выше. Мне еще ни разу не понадобились управляемые формы

[AlexVinS]

Зато надежность , гибкость, и скорость гораздо выше. Мне еще ни разу не понадобились управляемые формы

Управляемые формы и есть гибкость - реально декларативное описание интерфейса. А скорость для тех задач, для которых 1С обычно используется, вполне устраивает, если не забывать профилировать код , а для полной трехзвенки еще и на стороне СУБД контролировать производительность. На счет надежности, к версии 8.2 претензий нет.