Почему нет отечественных программ для бизнеса?

[Stasroot1]

и опять же это пока всего лишь обсуждения. если десктопные приложения писать проще то можно так и делать. как говориться, зачем делать что то забираясь в гору, если ее можно объехать по дороге вокруг. :-) а с другой стороны... вебориентированный вариант понастоящему кроссплатформенный для клиентов уж точно. ИМХО.

[villager]

Web/Desktop - какая разница?
если хранить описание интерфейса отдельно от программы - тогда легко будет менять отображение этого описания в (например) QT, на отображение в Web. Т.е. генерим не объект-окно для десктопа, а веб-страницу для браузера

но вообще, я - за десктоп.

[Voral]

ПС. Посмотрел бизнес-пак. Прикольно конечно, но изврат тот еще....

Может и изврат. Но я им пользуюсь уже фиг знает сколько лет. И для нужд ИПшника он меня устраивает почти полностью (по функционалу).

[Voral]

хм... я не берусь что то конкретно утверждать. но пожалуйста объясните почему не php и mysql? Я понимаю что вы можите спросить у меня в свою очередь, а мол какие я вижу плюсы минусы в этом. я пока промолчу наверное.

Вы еще забыли добавить html.
1. Php еще ладно (хотя скомпилированный код будет побыстрее отрабатывать, ди и вообще например Си более гибкий [если что я профессионально и с Cи/Си++ и c php работаю])
2. MySQL впринципе хорош, но все же уступает, например, Firbird'у по доступным .... функциям.
3. HTML. Интерфейс получится менее гибкий. Точнее порой будем упираться в ограничения по построению интерфейса. Кроме того придется привлекать JS. И бороться с разными браузерами.

Плюс от этой связки один. Пользователь в любой момент может подправить любой функционал системы без перекомпиляции. Между тем если сделать систему грамотно это не потребуется. (точнее потребуется крайне редко)

[Voral]

Вообще мое видение проекта.

Естественно клиент сервер.
Я бы выбрал Firebird. Я с ним уже 10 лет плотно работаю (несколько дней назад юбилей этого "события" был). Сравнивал с MSSQL (это отбрасываем сразу ), с Oracle (мне показался он более монстроидальным, есть ли у него бесплатные версии, что бы перенести базу на другой комп, на сколько я помню, надо выполнить операцию типа юэкапа, просто копирование не потянет), мускул - не достаточно развит по функционалу. ВФаерберд за 10 лет работы (под моим наблюдениям работают порядка 20-30 баз) он ни разу не подводил (были крушения базы но из-за нерадивых админов - то крах винта проморгали, то сервак всякой фигней забили, что винда глючить начала, последние 5 лет все уже наученые и все работает гладко). Самая большая база на сегодняшний день порядка 20Гб. С ней работают ориентировочно 30-50 пользователей. Можно использовать права доступа на уровне базы. А так хранимки. и UDFки (т.е. компилированные модули выполняемые на стороне сервера)

Как вариант можно вообще не првязываться к конкретной базе.... Но ИМХО в этом варианте больше минусов чем плюсов.

Далее по самой проге...

Имхо сначала нужен движек. Который будет предоставлять доступ к БД, организовывать меню, возможно рулить правами доступа. Все остальное на уровне подключаемых модулей. Возможно работу с БД можно вынести в отдельный модуль. Возможно есть смысл не давать доступ каждому модулю самостоятеьно работать с БД.

А так весь остальной функционал в модуле. Каждыей должен двать инффу о нужном для него меню, собственном функционале и т.п.
Важно только хорошо продумать интерфейс взаимодействия движка и модулей.

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

Если работу с БД вывести в отдельный модуль. То тут легче мы с можем портировать на любую БД (если возникнет такая необходимость), легче управлять доступом....

Возможно (но не уверен) можно сделать модуль отвечающий за интерфейс. Каждый модуль сообщает ему, каие элементы ему нужны. А этот организует окна с, вохможно, налолжением общего функционала

[Voral]

Да. По Firebird я имел дело и с репликацией. Есть готовые решения для облегчения этой процедуры правда под винду и платные .... Но я уже с этой системой достаточно разобрался. Если что....

[villager]

Имхо сначала нужен движек. Который будет предоставлять доступ к БД, организовывать меню, возможно рулить правами доступа. Все остальное на уровне подключаемых модулей. Возможно работу с БД можно вынести в отдельный модуль. Возможно есть смысл не давать доступ каждому модулю самостоятеьно работать с БД.

+500
и с помощью движка можно попробовать организовать работу с несколькими БД.
Т.к. штуки вроде бизнеспака хороши при беспроблемной инсталляции. Для таких вариантов - SQLite. Для тяжелых случаев - тяжелые БД.
я для доступа к БД использую средства QT (хотя поначалу изобретал велосипед).

какие будут предложения по части интерфейса?

[Voral]

и с помощью движка можно попробовать организовать работу с несколькими БД.

Я не уверен в необходимости работы с несколькими БД. Тогда придется убирать из БД все возможные хранимки, разграничения прав пользователей и оставлять все это на стороне клиента.
С одной стороны большая база от этого будет тяжелее обрабатываться.
С другой стороны ваерберд не монстр, ни кких проблем с установкой нет. И маленькой базе от него плохо не будет.

Если ориентироваться не на одну базу, а на несколько. Придется в плане работы с базой ориентироваться на худшую.....

ИМХО

[Stasroot1]

и с помощью движка можно попробовать организовать работу с несколькими БД.

Я не уверен в необходимости работы с несколькими БД. Тогда придется убирать из БД все возможные хранимки, разграничения прав пользователей и оставлять все это на стороне клиента.
С одной стороны большая база от этого будет тяжелее обрабатываться.
С другой стороны ваерберд не монстр, ни кких проблем с установкой нет. И маленькой базе от него плохо не будет.

Если ориентироваться не на одну базу, а на несколько. Придется в плане работы с базой ориентироваться на худшую.....

ИМХО

ИМХО для малого бизнеса и среднего вполне достаточно одной БД. численность пользователей до 250. разграничивать права доступа на уровне БД... а как реализовывать? множество подключений к БД под разными учетками? Не проще ли организовать грамотное разграничение прав доступа к данным на уровне движка а не на уровне БД? А то если я правильно понимаю у нас получиться двойная проблема с правами и на уровне БД прдумывать и на уровне приложения...(движка).

[Voral]

данным на уровне движка а не на уровне БД? А то если я правильно понимаю у нас получиться двойная проблема с правами и на уровне БД прдумывать и на уровне приложения...(движка).

Ни какой проблемы. Все настройки прав в интерфейсе программы. Что касается программы так тут и останется, что касается БД пропихнется туда.

[BIgAndy]

. а как реализовывать? множество подключений к БД под разными учетками?

Да. Кроме того хочется напомнить про существующий pam_postgresql и возможность отобраения пользователй линукса на роли в postgres. Не помню уже как там в файрбёрде

Не проще ли организовать грамотное разграничение прав доступа к данным на уровне движка а не на уровне БД?

Нет не проще. (за исключением того случая, когда движок реализован средтсвами RDBMS (на чем я, кстати, настаиваю)

А то если я правильно понимаю у нас получиться двойная проблема с правами и на уровне БД придумывать и на уровне приложения...(движка).

Никаких проблемм с этим не существует. Преимущества реазизации аутентификации средствами RDBMS еще и в том (по крайне мере в Postgres, DB2 и Oracle), что права можно раздавать на колонки (поля) и строки (записи) в таблицах и вьюшках(кортежах), на хранимые процедуры и функции. Эта возможность снимет еще кучу головной боли и необхлодимость писать лишний код

[trdm]

хм... я не берусь что то конкретно утверждать. но пожалуйста объясните почему не php и mysql? Я понимаю что вы можите спросить у меня в свою очередь, а мол какие я вижу плюсы минусы в этом. я пока промолчу наверное.

Вы еще забыли добавить html.

А разве php работает без htm на стороне пользователя? ))))

ПС. Посмотрел бизнес-пак. Прикольно конечно, но изврат тот еще....

Может и изврат.

Не "может" а изврат. Интерфейс бизнеспака думаю это наследие DOSa - эмуляция многооконности.
Нормальный MDI с нормальным меню уже не приветствуется? странно...

[Voral]

А разве php работает без htm на стороне пользователя? ))))

php как таковой? Да. Устанавливаете php. Устанваливаете скрипт. Объясняете системе чего делать "при клике" на файле с расширением php. Я его всегда с собой на флэшке возил для решения одноразовых задач, по перегону с dbf и csv в firebird.
Ну это лирика. Главное, что html не достаточн гибкий инструмент.

Интерфейс бизнеспака думаю это наследие DOSa - эмуляция многооконности.

Мне как пользователю фиолетово наследие чего он. Я его не по интерфейсу оцениваю, а по функционалу. В прочем если бы он устраивал меня на 100% то возможно меня бы и не было в этой теме....

И когда я соглашался с что то вроде БизнесПака имел ввиду не интерфейс, а функционал

[villager]

и с помощью движка можно попробовать организовать работу с несколькими БД.

Я не уверен в необходимости работы с несколькими БД. Тогда придется убирать из БД все возможные хранимки, разграничения прав пользователей и оставлять все это на стороне клиента.
С одной стороны большая база от этого будет тяжелее обрабатываться.
С другой стороны ваерберд не монстр, ни кких проблем с установкой нет. И маленькой базе от него плохо не будет.

Если ориентироваться не на одну базу, а на несколько. Придется в плане работы с базой ориентироваться на худшую.....

ИМХО

для реализации стандартных функций (insert update select) не надо задействовать ХП, а для ядра ничего другого и не надо. ХП понадобятся для реализации конкретных приложений и каждый сможет их задействовать в своей "конфигурации", как и другие особенности конкретной БД.
Это при условии, что мы говорим о конструкторе для создания учетных систем. Если говорить о жестком кодировании учетных функций в системе - тогда да, но такая система никому не нужна.
Нужна возможность быстро собирать работоспособную и легко развиваемую систему, причем с минимальной квалификацией программиста.

и еще плюс универсального ядра - не придется спорить, у какой бд хп длинней
и права доступа автоматом разместятся в движке

[BIgAndy]

и еще плюс универсального ядра - не придется спорить, у какой бд хп длинней
и права доступа автоматом разместятся в движке

Я одного не могу понять. А нафик тогда линукс? Есть маздай, где подобная архитектура оправдана.

работоспособную и легко развиваемую систему, причем с минимальной квалификацией программиста.

Вот здесь категорически не согласен. не должны быть системы такого уровня доступны эникейщикам. Учетные программы н требуют гибкости. А программы-помощники должны настраиваться профессионалами для профессионалов.
Бизнес правила должны быть забиты в RDBMS или в OLAP/OLTP сервер. (при трехзвенной архитектуре.
Еще раз: повторять маздайные решения нет никакой еобходимости. Они есть и работают в вайне весьма зорово.

[villager]

Я одного не могу понять. А нафик тогда линукс? Есть маздай, где подобная архитектура оправдана.

а какая архитектура оправдана в линуксе? (это я серьезно, без сарказма)

Вот здесь категорически не согласен. не должны быть системы такого уровня доступны эникейщикам. Учетные программы н требуют гибкости. А программы-помощники должны настраиваться профессионалами для профессионалов.
Бизнес правила должны быть забиты в RDBMS или в OLAP/OLTP сервер. (при трехзвенной архитектуре.
Еще раз: повторять маздайные решения нет никакой еобходимости. Они есть и работают в вайне весьма зорово.

такая система должна быть доступна аналитикам, способным внедриться на крупных предприятиях, а также студентам, способным автоматизировать соседний ларек. Все профи побыли эникейщиками
и это должно быть проще, чем 1ц
и должно быть быстрее и надежней
и работать не только на линуксе

никакой религии, только дело

ИМХО

зы: готов поучаствовать в таком проекте в любом случае

[BIgAndy]

а какая архитектура оправдана в линуксе? (это я серьезно, без сарказма)

По крайней мере должно использовать преимущества PAM. И мостиками pam->RDBMS. (pam_postgresql, pam_db2, pam_oracle) существуют. Кроме того в самих RDBMS есть модули и возможности мапить пользователй БД на пользователей OS. Что важно в случаях применения виндус.

такая система должна быть доступна аналитикам, способным внедриться на крупных предприятиях,

Вот ее надо сразу и предусматривать. В такой архитектуре нет ничего сложного. И доступна студентам второго курса.

а также студентам, способным автоматизировать соседний ларек. Все профи побыли эникейщиками

Совершенно верно.

и это должно быть проще, чем 1ц

Поэтому не надо делать ошибки 1С. Они всю логику перенесли с уровня БД на уровень придожения. Хот с этими задачами прекрасно справляется (и лучше спраляется RDBMS)

и должно быть быстрее и надежней

Вот вы и сами делаете правильные выводы

и работать не только на линуксе

Вот поэтому RDBMS + [OLAP/OLTP] + OOBase.

никакой религии, только дело

Ну и религию можно приплести. ЖВ Решение должно быть кошерным и православным

[antares0]

И что интересно никто даже не вспомнил о бизнес-логике. Я уж не говорю о ее сохранении.
Зато движок каждый третий уже написал а каждый второй уже пишет. Я првда не исключение в этом параде.

[antares0]

Бизнес правила должны быть забиты в RDBMS или в OLAP/OLTP сервер. (при трехзвенной архитектуре.

После чего они валяются мертвым хламом в чулане у DBA, которому они нафиг не нужны.
Я не то что бы сторонник 1С, но такой вариант не менее грустен.

[antares0]

а какая архитектура оправдана в линуксе? (это я серьезно, без сарказма)

По крайней мере должно использовать преимущества PAM. И мостиками pam->RDBMS. (pam_postgresql, pam_db2, pam_oracle) существуют. Кроме того в самих RDBMS есть модули и возможности мапить пользователй БД на пользователей OS. Что важно в случаях применения виндус.

"пользователь ОС" нифига не равно "Пользователь программы для бизнеса"
Сваливать авторизацию на СУБД это как-то непрвильно. В определенных случаях возможно, но кривизна от этого не исправляется.

[Doublespace]

Относительно firebird есть примеры баз и на сотни гигов, и даже до терабайта ( вчера попались примеры)

[hudyakov74]

Интересно читать. но думаю это все фантазии. в нашей настоящей модели мира общества потребления хорошо то, что продается. да есть те кто абстрагируется от этого и желает лучшего, но
1. Мы ограничены тем уровнем технологий которые на сегодня созданы и мыслим в категориях этих технологий. сами технологии создавались огромным трудом многих людей и временем со сменой поколений программистов. боюсь что бы мы не делали получится в лучшем (в очень хорошем) случае опять 1с, сап, аксапты и прочее - думаю их очень много умных людей делали.
2. хорошо то что продано, используется то что продано... это и про 1с и про виндовс, и про фери. и чтобы это было использовано как одно из первых условий оно должно быть продано. тогда жалея о безжалостно потраченном прийдется в этом работать, а там глядишь и другие проникнутся(станут счастливыми обладателями).
3. продуктов без недостатков нет. и все мы подсаживаем клиентов на себя и получаем за это бабки. это узкая мысль :-) зато рыночная.
4. умные и одинокие - таких много... время одиночек давно кончилось. либо надо быть организатором, либо в команде, либо гением...
5. обучение программиста на поддержку системы и ее внедрение в среднем занимает... а кстати сколько бы вы думали??? уже это дорого. при чем все должно ориентироваться на человека среднего ума... некачественная поддержка 1с со стороны незнающих внедренцев - это недоработанная программа. нельзя ориентироваться в технологиях на 100% знающих.

[Voral]

1. Мы ограничены тем уровнем технологий которые на сегодня созданы и мыслим в категориях этих технологий. сами технологии создавались огромным

хм. ну и что? Просто проект будет начат с более высокого уровня чем та же 1С. Можно учесть недостатки ее и аналогов. А потом, для начала ни кто и не собирается за пару месяцев превзойти 1С.

2. хорошо то что продано, используется то что продано...

Хорошо то, что делается пряморукими людьми. Единственное различие: продаваемые программы доходят до релиза быстрее

3. продуктов без недостатков нет. и все мы подсаживаем клиентов на себя и получаем за это бабки. это узкая мысль :-) зато рыночная.

И? Ни кто не запрещает обслуживать продукт (если все же дойдет до создания) за деньги. Имхо от этого только польза будет.

4. умные и одинокие - таких много... время одиночек давно кончилось. либо надо быть организатором, либо в команде, либо гением...

Все правильно. Вариться каждому в своем соку это глупо. Поэтому здесь и велось совместное обсуждение.

5. обучение программиста на поддержку системы и ее внедрение в среднем занимает... а кстати сколько бы вы думали???

Хм. А здесь где разве промелькивало "вытесним 1С с рынка"? Нет. Я сам бы стал ей и пользоваться, и еще на фирме жены бы внедрил. И обслуживал, и внедрял и, по возможности, прямо на месте баги правил........

Система то прежде всего для самих себя, а не что бы сделать всему миру "здоровски".

Жаль конечно тема подзатухла. Сформировать бы нечто типа зачатка ТЗ, плана и направления движения. Глядишь бы, что то и вытанцовывалось... К сожалению у меня сейчас время на 0

[villager]

Интересно читать. но думаю это все фантазии. в нашей настоящей модели мира общества потребления хорошо то, что продается. да есть те кто абстрагируется от этого и желает лучшего, но
1. Мы ограничены тем уровнем технологий которые на сегодня созданы и мыслим в категориях этих технологий. сами технологии создавались огромным трудом многих людей и временем со сменой поколений программистов. боюсь что бы мы не делали получится в лучшем (в очень хорошем) случае опять 1с, сап, аксапты и прочее - думаю их очень много умных людей делали.
2. хорошо то что продано, используется то что продано... это и про 1с и про виндовс, и про фери. и чтобы это было использовано как одно из первых условий оно должно быть продано. тогда жалея о безжалостно потраченном прийдется в этом работать, а там глядишь и другие проникнутся(станут счастливыми обладателями).
3. продуктов без недостатков нет. и все мы подсаживаем клиентов на себя и получаем за это бабки. это узкая мысль :-) зато рыночная.
4. умные и одинокие - таких много... время одиночек давно кончилось. либо надо быть организатором, либо в команде, либо гением...
5. обучение программиста на поддержку системы и ее внедрение в среднем занимает... а кстати сколько бы вы думали??? уже это дорого. при чем все должно ориентироваться на человека среднего ума... некачественная поддержка 1с со стороны незнающих внедренцев - это недоработанная программа. нельзя ориентироваться в технологиях на 100% знающих.

1.мыслим СВОИМ шаблонами, чужие мнения слушать - тяжело
2.продать можно все, что угодно. И это не обязательно будет хорошо (хотя продавцу будет ). А нам тут продавать еще нечего...
3.лучше сказать - у любого продукта есть преимущества (поэтому они и продаются)
4.с организатора сразу потребуют денег, гения - закидают дерьмом моментально, а команда без первого и второго не соберется
5.лучше меньше, да качественнее - долой "незнающих внедренцев"

но это все слова... хочется ближе к делу.

я слабо представляю совместную разработку, но если кого-нибудь интересует тема python+Qt - смотрите наработки здесь - пишите в личку
а вдруг ?

[skmdeveloper]

Почитал я эту и соседние ветки. И пришел к неутешительному выводу. К сожалению большинство так и не избавилось от так называемого "синдрома Windows". В то время как в Win постепенно избавляются от него, совершенно неуместно переносить на Линукс эти атавизмы типа монолитных программ, бизнес-логику в СУБД и пр. Если в проприетарном ПО это можно компенсировать ударным трудом толпы быдлокодеров, то в СПО такой путь тупиковый. Пример "Ананаса" который пилят с незапамятных времен и не могут довести до работоспособного состояния - самое яркое тому подтверждение. Не нужно наступать на чужие грабли.

Для справки. "Синдром Windows" - это философия UNIX со знаком минус.

Философия UNIX

# Правило модульности: Пишите простые части, соединяемые понятными интерфейсами.
# Правило ясности: Ясность лучше заумности.
# Правило композиции: Разрабатывайте программы так, чтобы их можно было соединить с другими программами.
# Правило разделения: Отделяйте правила (policy) от механизма (mechanism); отделяйте интерфейс от движка (engine).
# Правило простоты: Нацельтесь на простоту; добавляйте сложность, только где необходимо.
# Правило экономности: Пишите большую программу только когда можно продемонстировать, что другими средствами выполнить необходимую задачу не удастся.
# Правило прозрачности: Разрабатывайте прозрачные программы для облегчения последующего пересмотра и отладки.
# Правило надёжности: Надёжность — дитя прозрачности и простоты.
# Правило представления: Храните знания в данных так, чтобы логика программы была тупой и надёжной.
# Правило наименьшего удивления: При разработке интерфейса всегда делайте как можно меньше неожиданных вещей.
# Правило тишины: Если программе нечего сказать, пусть лучше молчит.
# Правило восстановления: Если надо выйти из строя, делайте это шумно и как можно быстрее.
# Правило экономии: Время программиста дорого; сократите его, используя машинное время.
# Правило генерации: Избегайте ручного набора кода; при любом удобном случае пишите программы, которые бы писали программы.
# Правило оптимизации: Сначала — опытный образец, потом — «причесывание». Добейтесь стабильной работы, только потом оптимизируйте.
# Правило многообразия: Отвергайте все утверждения об «единственно правильном пути».
# Правило расширяемости: Разрабатывайте для будущего. Оно наступит быстрее, чем вы думаете.

Эти принципы продемонстрировали свою эффективность, и чем дальше тем больше становится ясна их правильность.

Поэтому если ПО хочет быть жизнеспособным, то оно не должно представлять из себя мешанину из кода, описания интерфейса, и тем более SQL запросов.

[skmdeveloper]

И что интересно никто даже не вспомнил о бизнес-логике. Я уж не говорю о ее сохранении.
Зато движок каждый третий уже написал а каждый второй уже пишет. Я првда не исключение в этом параде.

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

[trdm]

Для справки. "Синдром Windows" - это философия UNIX со знаком минус.

Как потребитель продукции на платформах Windows и Linux могу сказать, что меня не удовлетворяет Linux-о построенные приложения.
Я устал от кучи скриптов с гигантскими зависимостями, устал от отсутствия единого центра управления, от манов,
которые не ставятся по умолчанию, от разных названий софтин со сходным функционалом и т.п.
нечего гнать на Windows, коли рожа кривая.
Чем больше пользую линукс тем больше его хочется выкинуть на помойку. Да в нем есть удобные и продуманные вещи.
Но большинство вещей сделано так, что-бы затруднить их использовать.
Это я как пользователь продукта заявляю.

[watashiwa_daredeska]

Чем больше пользую линукс тем больше его хочется выкинуть на помойку.

You are welcome.

Это я как пользователь продукта заявляю.

Продукта «Linux» в природе не существует.

[watashiwa_daredeska]

Я устал от кучи скриптов с гигантскими зависимостями, устал от отсутствия единого центра управления, от манов, которые не ставятся по умолчанию, от разных названий софтин со сходным функционалом и т.п.

Зависимости скриптов меня ни разу не напрягают — этим заведует APT, и делает это более чем хорошо. Единый центр управления да, отсутствует, их два: /etc и ~, управлять можно vim'ом. Пользовательские маны по-умолчанию ставятся, маны для разработчиков нужны не всегда, даже если ставятся инструменты разработчика. Много софтин со сходным функционалом — это хорошо, это надежно. Если одну софтину бросили, сломали или прикрутили к ней что-то совсем отвратительное, можно воспользоваться другой. В любой момент.

Это я заявляю как пользователь продукта Debian GNU/Linux :)

[trdm]

Это я как пользователь продукта заявляю.

Продукта «Linux» в природе не существует.

+

Это я заявляю как пользователь продукта Debian GNU/Linux

)