Чтобы влезть со своим двигателем… это просто нереально, говорю как сотрудник электромашиностроительного завода как раз и выпускающего электродвигатели.
create sequence aaa;
with price(stock_id, prod_id, start_date, kind, price1, cost1, bonus1) as (
values (1,1,to_date('2000-01-01','YYYY-MM-DD'),'R',100.0,32.12,6.49),
(1,1,'2000-01-02','P', 80.0, 0, 0),
(1,1,'2000-01-03','P', 70.0, 0, 0),
(1,1,'2000-01-04','R',110.0,33.48,6.19),
(1,1,'2000-01-05','P', 90.0, 0, 0),
(1,1,'2000-01-06','R',120.0,41.22,6.19),
(1,1,'2000-01-07','P', 80.0, 0, 0),
(1,1,'2000-01-08','P', 90.0, 0, 0),
(1,1,'2000-01-09','R', 93.0,36.87,6.49),
(1,1,'2000-01-10','R', 94.0,36.85,6.99),
(1,2,'2000-01-01','R',101.0,52.06,9.00),
(1,2,'2000-01-02','P', 81.0, 0, 0),
(1,2,'2000-01-03','P', 71.0, 0, 0),
(1,3,'2000-01-04','R',111.0,64.96,4.50),
(1,3,'2000-01-05','P', 92.0, 0, 0),
(1,3,'2000-01-06','R',122.0,66.83,4.60),
(1,3,'2000-01-07','P', 82.0, 0, 0),
(1,3,'2000-01-08','P', 92.0, 0, 0)),
q_price as (
select *, case when kind = 'R' then nextval('aaa') else currval('aaa') end as rn
from price),
r_price as (
select *, dense_rank() over (partition by stock_id, prod_id, rn order by stock_id, prod_id, start_date) as dr
from q_price)
select *, lag(price1, dr::int-1) over (partition by stock_id, prod_id, rn order by stock_id, prod_id, start_date) as price1x from r_price p order by stock_id, prod_id, start_date;
Вот Вам пример. Есть отдел УМ, принимает заказы, согласовывает с конструкторами, технологами, поставкой, производством. УМ отвечает зарплатой за отгруженную вовремя продукцию. Пока всё хорошо. Но, существующая действительность не настолько идеальна. Временами, сотрудникам УМ приходится бегать на производство к самым различным работникам: диспетчерам, мастерам, распредам… и просить/проталкивать свой заказ. Автоматизировать этот бардак? Да, на это закрывают глаза годами :) Хотя в последнее время прогресс на лицо, начали с формализации бизнес-процессов и оптимизации производственных потоков. Где-то ближе к концу замаячит CRM :)
Поясню свой вопрос, переход на альтернативную систему планирования — далеко не самый дешёвый как в плане времени производства, так и человеко-часов программистов. Написание такого планирования с нуля — это даже не 3-5 программистов…
Я скорее имел ввиду идеологию подхода в разных ОС, например, захотели 2-й питон, зашли в те же порты, поставили, захотели 3-й питон, зашли и поставили. Что замечательно, так это то, что они сосуществуют вместе со всеми своими либами и зависимостями в одной ОС и без контейнеров (да, jail есть и это рабочий инструмент для продакшена). Аналогично и с другими проектами. В линуксе, что не день, то сюрприз. Опять же пример, вечером уходил — всё работало, утром запустил компьютер и нет модуля управления рабочими столами, обновил ОС (centos), пропала менюха.
Как я вижу, во FreeBSD ОС — это комплект ядра, окружения, и даже пакетов. В Линуксе, больше выбор, но приходится платить за это кровью админов)))
Мне кажется, что вы несколько однобоко подошли к вопросу. Сейчас большинство перечисленных пунктов — это продвинутый сисадмин. CIO же уже в первую очередь руководитель, который одной ногой в бизнес-процессах, другой ногой в менеджменте, руками в понимании администрирования и программирования. Он уже руководитель, который видит глобальную цель. Да, желательно чтобы он разбирался в технологиях, но достаточно в том объёме, чтобы понимать потраченные пару дней админом на настройку сервера или программистом на рефакторинг кода стоили того.
Если сопоставить цену весов с таким экраном и их количество с ЗП ещё одного гастарбайтера, то последнее будет просто невесомо)))
И может будет дешевле купить весы попроще, а за ними повесить большой баннер?
Возможно, если заказчик и исполнитель одно лицо, то возможности пофантазировать разработчику будет поболее. Он, заказчик, сам определяет сроки и функционал решения, в котором программисты не просто кодеры, а люди обязанные разбираться в предметной области, для чего пишется программное решение.
У нас скорее всего «неправильное» решение, самописное. Т.к. как и вы не смогли найти готового, которое бы было и удобным и функциональным. Только подсказку сделали не по букве i, а при наведении мышкой (да-да на планшеты мы не особо ориентировались на начальном этапе, переделаем вскоре). Неправильную раскладку обходим обычной таблицей соответствия.
Я бы высказался более обширно… Если вам нужен word, crm, бухгалтерия и т.д. в области типовых решений — берите готовый продукт и не засоряйте мозги разработчиков изобретением велосипеда. Однако, если у вас нечто большее, как система управления производством, ну или попроще как у товарища AslanKurbanov, то самописный продукт — это уже конкурентное преимущество. Но не надо быть наивным и думать, что самописка — это чистый JS и голый html c php. Если позволительно и применимо, то можно использовать готовые фреймворки, даже ту же 1С. Когда требуется нечто большее и хочется быстрее/гибче, пусть будет, например, php+postgresql, а связь с внешними системами через выгрузку или прямой sql.
Кстати, про самописку, никто кроме «своих» программистов не может знать лучше и обширнее предметную область куда идёт написанный продукт. По крайней мере у нас на заводе так :)
Прошу прощения, чуть выше не в том месте ответил…
У нас директор имеет крайне категоричное мнение — всё своё ношу с собой, т.е. никаких облаков, только у себя. Вот и вопрос, локально можно ждать какие-то плюшки из облака, конкретно конечно это замена СУБД на PostgreSQL и очереди?
Мысль про Pervasive в вашем ответе была именно о переходе на облако?
У нас директор имеет крайне категоричное мнение — всё своё ношу с собой, т.е. никаких облаков, только у себя. Вот и вопрос, локально можно ждать какие-то плюшки из облака, конкретно конечно это замена СУБД на PostgreSQL и очереди?
Мысль про Pervasive в вашем ответе была именно о переходе на облако?
Позже на сервер начали ставить Pervasive SQL, который, в принципе, давал возможности доступа через SQL, но она не использовалась системой СБиС.
Вы не поверите, но мы радовались как дети, когда получилось настроить Pervasive для СБиС'а в качестве настоящего SQL сервера через протокол brtv. Правда пришлось использовать ещё дополнительный костыль в виде ODBCproxy из-за того, что данные требовались в нашей системе под UNIX. В итоге сейчас мы можем НАСТОЯЩИМИ селектами тягать данные из СБИС'овской базы. Но какой же этот Pervasive меедленный и кастрированный, ужас…
Поделитесь, пожалуйста, фичами из п3
И какой версией ceph баловались? :)
with price(stock_id, prod_id, start_date, kind, price1, cost1, bonus1) as (
values (1,1,to_date('2000-01-01','YYYY-MM-DD'),'R',100.0,32.12,6.49),
(1,1,'2000-01-02','P', 80.0, 0, 0),
(1,1,'2000-01-03','P', 70.0, 0, 0),
(1,1,'2000-01-04','R',110.0,33.48,6.19),
(1,1,'2000-01-05','P', 90.0, 0, 0),
(1,1,'2000-01-06','R',120.0,41.22,6.19),
(1,1,'2000-01-07','P', 80.0, 0, 0),
(1,1,'2000-01-08','P', 90.0, 0, 0),
(1,1,'2000-01-09','R', 93.0,36.87,6.49),
(1,1,'2000-01-10','R', 94.0,36.85,6.99),
(1,2,'2000-01-01','R',101.0,52.06,9.00),
(1,2,'2000-01-02','P', 81.0, 0, 0),
(1,2,'2000-01-03','P', 71.0, 0, 0),
(1,3,'2000-01-04','R',111.0,64.96,4.50),
(1,3,'2000-01-05','P', 92.0, 0, 0),
(1,3,'2000-01-06','R',122.0,66.83,4.60),
(1,3,'2000-01-07','P', 82.0, 0, 0),
(1,3,'2000-01-08','P', 92.0, 0, 0)),
q_price as (
select *, case when kind = 'R' then nextval('aaa') else currval('aaa') end as rn
from price),
r_price as (
select *, dense_rank() over (partition by stock_id, prod_id, rn order by stock_id, prod_id, start_date) as dr
from q_price)
select *, lag(price1, dr::int-1) over (partition by stock_id, prod_id, rn order by stock_id, prod_id, start_date) as price1x from r_price p order by stock_id, prod_id, start_date;
Как я вижу, во FreeBSD ОС — это комплект ядра, окружения, и даже пакетов. В Линуксе, больше выбор, но приходится платить за это кровью админов)))
И может будет дешевле купить весы попроще, а за ними повесить большой баннер?
Кстати, про самописку, никто кроме «своих» программистов не может знать лучше и обширнее предметную область куда идёт написанный продукт. По крайней мере у нас на заводе так :)
У нас директор имеет крайне категоричное мнение — всё своё ношу с собой, т.е. никаких облаков, только у себя. Вот и вопрос, локально можно ждать какие-то плюшки из облака, конкретно конечно это замена СУБД на PostgreSQL и очереди?
Мысль про Pervasive в вашем ответе была именно о переходе на облако?
Мысль про Pervasive в вашем ответе была именно о переходе на облако?
Вы не поверите, но мы радовались как дети, когда получилось настроить Pervasive для СБиС'а в качестве настоящего SQL сервера через протокол brtv. Правда пришлось использовать ещё дополнительный костыль в виде ODBCproxy из-за того, что данные требовались в нашей системе под UNIX. В итоге сейчас мы можем НАСТОЯЩИМИ селектами тягать данные из СБИС'овской базы. Но какой же этот Pervasive меедленный и кастрированный, ужас…