Форум: "Прочее";
Текущий архив: 2011.05.22;
Скачать: [xml.tar.bz2];
ВнизОпрос: Как вы учитываете изменения в бизнес-процессах Найти похожие ветки
← →
Игорь Шевченко © (2011-02-03 10:40) [0]Советуюсь с миром, как лучше учитывать изменения в бизнес-процессах, с наименьшими затратами на программирование.
Детализируя вопрос - есть некий набор условий с некоторыми критериями, по которым нужно сегодня производить расчеты. Завтра коммерсанты решают, что для большей эффективности надо применять другие критерии или другие условия, и расчеты меняются. Каждый раз вносить изменения в программу, будь то клиентская или серверная часть - наверное не очень эффективно. Придумывать свой метаязык для описания всех возмножных критериев предметной области - наверное довольно трудоемко, ну и т.д.
Интересует как удачный/неудачный опыт сообщества, так и мнение сообщества об оптимальных путях решения.
Идеальная цель - переложить изменения в бизнес-процессах на конечного пользователя по максимуму.
1С не предлагать :)
← →
KilkennyCat © (2011-02-03 11:20) [1]если преследовать идеальную цель, по-моему, без метаязыка никуда.
← →
oxffff © (2011-02-03 11:24) [2]Посмотреть на SAP R3.
В документе R3 есть вкладака "условия" с так называемыми условиями(виды промежуточных сумм из которых формируется итоговая сумма).
Человек настраивает алгоритм расчета оперируя условиями и связями между ними.
Я к сожалению не знаю как это делается. Но вроде удобно.
Понятное дело, что это некая таблица связок между условиями при изменении которых вызываются например callback других условий и т.д.
То есть расчет выпрямляется на набор условий которые вычисляются последовательно для получения итоговой суммы.
+ естественно проход по условиям управляется состоянием этих условий.
← →
И. Павел © (2011-02-03 11:27) [3]> Посмотреть на SAP R3.
Начать просмотр рекомендую с цены :)
Я SAP почти не занимаюсь, но у нас поддержкой одного только HR занимаются 5 программистов, так что это, видимо, тоже не панацея.
← →
oxffff © (2011-02-03 11:45) [4]
> но у нас поддержкой одного только HR занимаются 5 программистов,
+проектный офис + 3 уровня обработки заявки пока дойдет до программистов. Отсюда и цена + отстегивание в SAP ежегодное за user license.
← →
oxffff © (2011-02-03 11:46) [5]У нас HR, MM, FI, SD, TORO.
← →
Ega23 © (2011-02-03 11:46) [6]
> Начать просмотр рекомендую с цены :)
Ты пост-то прочитал, или нет? Или знакомое слово увидел - и как обычно в бой?
← →
Ega23 © (2011-02-03 11:47) [7]
> Отсюда и цена + отстегивание в SAP ежегодное за user license.
Цена там из-за ничем не обозначенной зарплаты консультантов и абаперов.
← →
И. Павел © (2011-02-03 11:51) [8]> [6] Ega23 © (03.02.11 11:46)
А вам, похоже, для того чтобы начать флудить и знакомого словаачала не нужно...
Я сказал, что SAP не панацея по гибкости, позволяющая обойтись пользователям без программистов при изменении требований.
Что вам опять не по нраву? Поясните.
← →
12 © (2011-02-03 11:54) [9]SAP, сап.. панацея что ли?
Мне бывший начальник один сказал - Внедряем SAP. На вопрос примерно такой: "нахрена " ответил примерно так: "Нада".
На самом деле, думаю, Генеральный узнал, что с внедренным SAP контора будет стоит дороже..
(Тип менеджера №1 из спича Константинова)
И не поспоришь же - как минимум на лицензию SAP :)
по сабжу - если б не ИШ был топик-стартером,
сказал бы что процедуры. Выделить и переписывать, по заказу/требованиям.
Так и делаю и делали до этого и пока SAP внедряли тоже так делали. А после я ушел, но подозреваю, что или еще народу больше стало, теперь SAP настраивают, или продолжают процедурки переписывать.
Но, так как ИШ, не скажу :)
← →
oxffff © (2011-02-03 11:56) [10]
> Генеральный узнал, что с внедренным SAP контора будет стоит
> дороже..
Это единственный плюс SAP.
← →
Sergey Masloff (2011-02-03 11:59) [11]12 © (03.02.11 11:54) [9]
Ну а если историчность нужно сохранить? И на любой момент рассчитывать по правилам действующим на тот момент? А правила меняются раз в 2-3 месяца? А системе уже 15 лет
Подумай что за процедуры там будут
;-)
← →
Jeer © (2011-02-03 12:02) [12]Для OLAP и DataMining наличие метаязыка практически стандарт.
Поскольку я вплотную и долго занимаюсь OLAP для систем принятия решений, такой метаязык был введен в мои системы ( основан на одном из паскалевских скриптов).
В качестве примера таких систем (примерные аналоги моих систем):
http://www.prognoz.ru/ru/index.php
http://www.keysystems.ru/
http://infovisor.ivanovo.ru/
http://www.bars-open.ru/articles
← →
Ega23 © (2011-02-03 12:05) [13]
> Я сказал, что SAP не панацея по гибкости, позволяющая обойтись
> пользователям без программистов при изменении требований.
Ты сказал, что начинать надо с просмотра цены. И что поддержкой HR-модуля у вас 5 быдлокодеров занимаются.
Я не хочу никого обидеть, но 99,9% российских "специалистов"-сапёров являются быдлокодерами. Которые прослушали полугодичные курсы, более-менее знают структуру таблиц, умеют говорить умные слова "Это проблема в Базисе" и претендуют на зарплату от 100.000. Вот дословно вчерашний вопрос одно сапера (довольно толкового, между прочим):
Слушай, гуру, а вот скажи мне - что более правильно
1. Сделать ключ из 11 числовых полей по 10 знаков, из которых некоторые могут быть нолями
2. Склеить эти 11 полей в одно строковое и сделать по нему ключ
Это чисто для интереса.
У нас тут народ до меня реализовал пункт 2. Я вот пытаюсь понять - для чего так сделано:-(...
И такая хрень у них там - повсеместно.
Так что то, что у вас 5 человек этим занимается - это абсолютно ни о чём не говорит.
А Сергей рекомендовал Игорю саму идею, а не сам САП.
← →
И. Павел © (2011-02-03 12:11) [14]> [13] Ega23 © (03.02.11 12:05)
Артемий Лебедев скромко стоит в сторонке...
← →
Ega23 © (2011-02-03 12:22) [15]
> Артемий Лебедев скромко стоит в сторонке...
Ну давай послушаем мнения остальных наших коллег по форуму. Иксик вон САП-ом занимался. Тот же oxffff (Сереж, к вам же вроде "мацковские специалисты" приезжали, поделись мнением). Кто-то ещё точно был.
← →
oxffff © (2011-02-03 12:41) [16]
> Ega23 © (03.02.11 12:22) [15]
ABAP изучал сам по книжке, методом тыка, проб и ошибок.
Изучил сам. В коде постоянно использую метаописания, чтобы кто не знает не лез в мой код. Стараюсь писать сложно, очень сложно, чтобы только я смог разобраться.:)
Приезжал на курсы SAP Enjoy Controls рассказывали как создавать объекты, вызывать методы, устанавливать свойства.
Запомнилось только постоянные чаепития во время обучения. И это не только в SAP. Видимо вообще западная технология купить клиента недорого, чтобы сосать из него бабло.
Что касаемо специалистов. Меня раздражают 3 уровня между программистами и заказчиками. Постоянные селекторы и всякая другая шляпа выкручивают мозг. У нас в кабинете сидит специалист по HR.
Хочется дать иногда пендаля всему HR. И сказать может вы ребята прекратите заниматься ... и обсуждать умными словами очень простую бизнес логику.
Порой думаешь им походу самим нравиться выпячивать свое Я за счет непонятных другим словечек. Расчет зарплаты и выплат настраивают постоянно. Постоянные звонки над ухом. И трындешь.
И постоянно вылезают грабли. А бизнес логика проробатывалась 3 уровнями до внедрения. А почему тогда не работает? :)
Вот такое мое мнение.
P.S.
Мы сами больше по FI, SD, MM и взаимодействию SAP с внешними системами.
+ все остальное что не связано с SAP.
← →
oxffff © (2011-02-03 12:43) [17]
> Стараюсь писать сложно, очень сложно,
На самом деле стараюсь писать обобщенно с просмотром на несколько шагов вперед. Поскольку приходилось переписывать логику прописанную в коде. Стараюсь писать металогику, которая настраивается вне программы.
← →
oxffff © (2011-02-03 12:48) [18]Теперь насчет программистов для SAP. Я думаю, что хороших программистов мало. Впрочем как и не только для SAP.
← →
Ega23 © (2011-02-03 12:48) [19]
> ABAP изучал сам по книжке, методом тыка, проб и ошибок.
Так у тебя был опыт нормального программирования и проектирования на другом языке. Принципы-то никуда не делись.
А у большинства до этих курсов - ну на VBA пяток-другой макросов под Excel написано. И несколько формочек в Access. И понтов после курсов - выше крыши.
← →
oxffff © (2011-02-03 12:50) [20]
> И понтов после курсов - выше крыши.
Все умрут и они тоже. :)
← →
clickmaker © (2011-02-03 13:18) [21]когда-то участвовал в разработке средней сложности erp для завода, так там и то не обошлось без примитивного метаязыка. Состоящего из набора действий, условий (отдаленно напоминающего сиквельный job) и простенького интерпретатора паскаль-подобного скрипта
← →
Игорь Шевченко © (2011-02-03 13:22) [22]Я наверное не так акценты расставил: то, что в SAP или аналогичных системах есть свои языки для описания бизнес-процессов это не то, что интересно. Интересна именно практика, какие решения вами (вашими знакомыми/незнакомыми) использовались в проектах или планируется использовать или использовали, но неудачно :)
← →
b z (2011-02-03 13:34) [23]У нас расчеты простецкие, поэтому не заморачиваясь прикрутили яваскрипт. Хранится в базе, считает либо на клиенте либо в прям базе, зависит как и откуда данные приходят.
← →
DiamondShark © (2011-02-03 13:45) [24]
> Игорь Шевченко © (03.02.11 13:22) [22]
Мы использовали всё: и просто детальные настройки, и сменные хранимки, и прикручивание скрипт-движков, и DSL, и визуальный дизайнер процессов.
Всё кончалось одинаково: нанимался кто-то, кто бы расставлял галки в настройках, допиливал хранимки, писал скрипты, описывал бизнес-логику в DSL или рисовал в дизайнере. Чуть менее, чем всегда, этим кем-то оказывалась наша же контора.
С тех пор идея "Клиент будет настраивать своё бизнес-приложение" однозначно относится к области утопий.
← →
euru © (2011-02-03 14:43) [25]
> Ega23 © (03.02.11 12:05) [13]
> что более правильно
> 1. Сделать ключ из 11 числовых полей по 10 знаков, из которых некоторые могут быть нолями
> 2. Склеить эти 11 полей в одно строковое и сделать по нему ключ
Первый вариант в большинстве случаев более предпочителен, потому что позволит делать выборки из таблицы по отдельным критериям ключа.
← →
euru © (2011-02-03 14:49) [26]
> oxffff © (03.02.11 12:41) [16]
> ABAP изучал сам по книжке, методом тыка, проб и ошибок.
Если она написана на русском языке, то я её, скорее всего, знаю. Для первого ознакомления почитать можно, а потом всё-таки лучше SAP Help.
> Что касаемо специалистов. Меня раздражают 3 уровня между
> программистами и заказчиками.
И какой уровень вы предлагаете исключить?
← →
12 © (2011-02-03 15:01) [27]>> И какой уровень вы предлагаете исключить?
может, добавить? :)
так хочу работать
1. Заказчик говорит человеку(Ч1), который понимает область разработки и имеет техн.склад ума.
2. Ч1 говорит человеку(Ч2), который умеет немного программировать и немного понимает область разработки, и имеет техн.склад ума. Ч1 и Ч2 составляют план, схему и сроки.
3. Ч2 идет к человеку(Ч3), который умеет программировать хорошо. Ч2 и Ч3 корректируют план, схему и сроки.
4. Ч3 сам делает или в команде. Периодически совещается с Ч2. Если Ч2 не копенгаген - он с Ч1 советуется. Ч1 с заказчиком.
а я где-то в отделе затесался :)
← →
Ega23 © (2011-02-03 15:04) [28]
> Первый вариант в большинстве случаев более предпочителен,
> потому что позволит делать выборки из таблицы по отдельным
> критериям ключа.
Предпочтительнее вариант создания суррогатного первичного ключа с наложением уникального индекса на все 11 полей.
ИМХО.
← →
oxffff © (2011-02-03 15:05) [29]
> euru © (03.02.11 14:49) [26]
>
> > oxffff © (03.02.11 12:41) [16]
>
> > ABAP изучал сам по книжке, методом тыка, проб и ошибок.
>
>
> Если она написана на русском языке, то я её, скорее всего,
> знаю. Для первого ознакомления почитать можно, а потом
> всё-таки лучше SAP Help.
>
>
> > Что касаемо специалистов. Меня раздражают 3 уровня между
>
> > программистами и заказчиками.
>
> И какой уровень вы предлагаете исключить?
Кречмер? :)
Я ничего не предлагаю. Мне представляется, что нельзя играть на западной балалайке восточные напевы. Три уровня это может быть неплохо.
Однако когда три уровня дублируют функции друг друга и факту просто перетасовывают работу между собой в России.
в итоге попадает программист, который может переделывать алгоритм по 10 раз поскольку уровни заняты собственной важностью.
Знаменитая переписка про рекламный щит очень показательна
http://abelomorov.livejournal.com/1542.html
Читать все части.
← →
oxffff © (2011-02-03 15:25) [30]
> а потом всё-таки лучше SAP Help.
Естественно потом был он. :)
← →
12 © (2011-02-03 16:04) [31]
> http://abelomorov.livejournal.com/1542.html
есть и такой случай
я, как дурак, на корпоративном сайте подписывался с визиткой внизу.
По-идее, так и нужно всем. Но у всех в профиле, а я решил для удобства пользователей, чтоб лишний раз не тыкали...
Теперь звонят и пишут по любой фигне... Даже которой не занимаюсь, даже которой не наш отдел занимается..
Лень искать конкретные номера - о, а этот, судя по коду, из того региона, оттуда, вроде - давай-ка позвоним ему.. А поднял трубку - посылать нельзя :)
вот я дурак.. :))
← →
euru © (2011-02-03 16:37) [32]
> 12 © (03.02.11 15:01) [27]
> может, добавить? :)
Развели бюрократию :)
Три уровня - это в большинстве случаев необходимое и достаточное количество:
1. Ключевой клиент (заказчик, пользователь) - хорошо знает предметную область, может объяснить поставленную задачу с точки зрения бизнес-логики, принимает дополнительные решения по возникающим по ходу разработки вопросам.
2. Бизнес-аналитик (специалист по модулю SAP) - знает предметную область, хорошо знает функционал модуля (от интерфейса до используемых в модуле таблиц), может оценить целесообразность задачи либо предложить альтернативные решения, в случае необходимости сделать постановку задачи для её реализации.
3. Системный аналитик (программист) - знает функционал, хорошо знает инструменты разработки, может оценить поставленную задачу и выбрать оптимальный способ её реализации, оформить техническое задание и на его основе реализовать поставленную задачу.
Естественно, каждый уровень может состоять при необходимости из нескольких человек.
В подавляющем большинстве случаев уровни 1 и 3 практически не взаимодействуют.
← →
Юрий Зотов © (2011-02-03 16:38) [33]> Сабж
Нечто похожее у меня сейчас сделано так.
1. Есть интерфейс IExecutable с методом Exec (и другими, если надо).
2. Есть абстрактный класс "Шаг алгоритма", реализующий этот интерфейс.
3. Есть наследники этого класса, в каждом из которых перекрыт метод Exec.
Наследники лежат в пакетах, а все пакеты лежат в обусловленном месте. В каждом наследнике метод Exec выполняет какую-то одну "атомарную" с точки зрения бизнес-логики операцию (например, проверку ФИО или зачисление денег на лицевой счет). Эти классы пишут программисты и постепенно накапливается библиотека шагов - то есть, программисты нужны все меньше и меньше.
4. Написав и отладив шаг, программист регистрирует его, прописывая в БД, в таблицу шагов. В ней указывается русское наименование шага, имя его класса, имя его пакета (и еще что угодно). Таким образом, ядро получает возможность загрузки и выполнения любого шага.
5. В ядре есть класс "Алгоритм", тоже реализующий интерфейс IExecutable. Он содержит упорядоченный список шагов. Метод Exec в нем проходит по этому списку и вызывает метод Exec каждого шага - то есть, выполняет последовательность "атомарных" бизнес-операций. Все эти операции выполняются в одной транзакции и если любой шаг выдал ошибку (или исключение), то выполнение алгоритма прерывается, транзакция откатывается, а юзер получает внятное сообщение (либо оно пишется в лог). Кроме того, любой шаг может прервать выполнение алгоритма и без выдачи ошибки.
6. Есть служебные таблицы БД и их визуальный редактор. В редакторе юзер (точнее, юзерский админ) простыми кликами мышки устанавливает:
- состав шагов каждого алгоритма и их последовательность;
- привязку алгоритма к конкретному типу документа.
Таким образом, один и тот же тип документа у каждого юзера может обрабатываться по-своему и эту настройку делает юзерский админ, просто кликая мышкой и используя готовую библиотеку шагов. Если требуется какая-то специальная обработка, для которой соответствующего шага в библиотеке еще нет, то только тогда привлекается программист для создания и регистрации в БД нового шага. С ростом библиотеки шагов программист становится нужен все меньше и меньше.
Это канва. В реальности все выглядит несколько хитрее. Например, любой шаг алгоритма может иметь параметры и работать в зависимости от их значений. Имена и количестов параметров устанавливает программист и, прописывая шаг в БД, там же прописывает имена и дефолтные значения параметров. Однако, админ юзера может изменить фактические значения параметров (тем же самым визуальным редактором) и сделать так, что один и тот же шаг получит разные значения параметров в зависимости от типа обрабатываемого документа.
Кроме того, в библиотеке есть шаги типа "if условие, то перейти к шагу номер N, иначе перейти к шагу номер M" - то есть, алгоритм можно ветвить и зацикливать. Такие настройки тоже делает админ все тем же редактором.
← →
euru © (2011-02-03 16:43) [34]
> Ega23 © (03.02.11 15:04) [28]
> Предпочтительнее вариант создания суррогатного первичного
> ключа с наложением уникального индекса на все 11 полей.ИМХО.
Вариант 2 (объединить 11 полей в одно поле) - это и есть суррогатный ключ.
Ваше решение - это объединение двух вариантов, т.е. вы предлагаете в таблице вести два ключа: суррогатный и по всем ключевым полям. Смысл?
← →
Ega23 © (2011-02-03 16:48) [35]
> Вариант 2 (объединить 11 полей в одно поле) - это и есть
> суррогатный ключ.
Нет. Суррогатный ключ - тупой счётчик, не несёт никакого логического смысла, кроме того, что гарантированно уникален.
Ну и сравнивать 2 целых числа - гораздо быстрее, чем сравнивать 2 строки длиной 121 символ.
← →
12 © (2011-02-03 16:52) [36]
> euru © (03.02.11 16:43) [34]
практически тот же, но не >>объединить 11 полей в одно поле
, а просто сказать СУБД, что эти 11 полей - ключ.
← →
12 © (2011-02-03 16:54) [37]
> Юрий Зотов © (03.02.11 16:38) [33]
а, по-чесноку, это работает?
в том смысле, что не "вот-вот еще допилим и они потом сами будут", а реально, они сами, средней сложности логику, строят?
← →
Ega23 © (2011-02-03 16:55) [38]
> а просто сказать СУБД, что эти 11 полей - ключ
Это и есть уникальный индекс. На первичный ключ в разных СУБД могут существовать ограничения (точно не помню, но для, например, MSSQL - общая длина поля, связано с тем, что первичный ключ кластерным индексом является, ну и с размером страницы).
← →
DiamondShark © (2011-02-03 16:56) [39]
> С ростом библиотеки шагов программист становится нужен все
> меньше и меньше.
А кликающий настройщик плавно превращается в программиста на вновь зародившемся DSL.
И круг повторяется.
;)
← →
Ega23 © (2011-02-03 16:58) [40]
> Юрий Зотов © (03.02.11 16:38) [33]
во, мы тоже подобную схему реализовывали.
← →
12 © (2011-02-03 17:06) [41]
> Ega23 © (03.02.11 16:58) [40]
и реализовали?
← →
Ega23 © (2011-02-03 17:17) [42]
> и реализовали?
Ага. Сейчас, правда, без содрогания не вспомнить. Как начальник сказал: "- Система приобретает вид лома с кучей конфигурируемых шарниров."
Но реальные инсталляции ещё при мне были (как раз когда по Дагестану мотался), потом ребята допилили до приемлемого уровня.
← →
Empleado © (2011-02-03 17:19) [43]
> Как вы учитываете изменения в бизнес-процессах
Из опыта:
Таблица с факторами влияющими на ценообразование.
В программе уже заложена функциональность, обеспечивающая учет уже существующих факторов, а также есть параметр(ы) для вкрапления новых, еще не присутствующих в таблице факторов.
Изменять/создавать факторы имеют право только Advanced Users нашего приложения.
(Схема работает 10 лет. Поставщики обновляют каталоги 1-2 раза в год, соответственно параметры меняются минимум 1-2 раза в год, иногда пользователи меняют 8-10 раз некоторые параметры некоторых совокупностей данных некоторых каталогов)
← →
12 © (2011-02-03 17:28) [44]
> Ega23 © (03.02.11 17:17) [42]
везет :)
ни разу не видел такую систему
1С, которую не предлагать :), тоже стала требовать программиста довольно скоро..
> Ega23 © (03.02.11 16:55) [38]
> для, например, MSSQL - общая длина поля, связано с тем,
> что первичный ключ кластерным индексом является
кстати, необязательно первичный ключ кластерным индексом является
это по умолчанию и по прямости рук так должно быть, но практика подносит сюрпризы.
← →
DiamondShark © (2011-02-03 17:44) [45]
> это по умолчанию и по прямости рук так должно быть
По умолчанию -- да. А вот с прямостью...
Представьте, что у вас превичный ключ -- какая-то хрень, которая не является монотонно возрастающей в порядке добавления. Например, GUID
Кластерный индекс по GUIDу -- это ад и израиль.
← →
Юрий Зотов © (2011-02-03 17:45) [46]> 12 © (03.02.11 16:54) [37]
> а реально, они сами, средней сложности логику, строят?
Строят, но не все. Те, кто не умеет (а скорее - не хочет) делать это сам, обращаются к разработчикам. Ну а пощелкать мышкой 5 минут за бабки клиента - что может быть приятнее?
← →
Ega23 © (2011-02-03 17:49) [47]
> кстати, необязательно первичный ключ кластерным индексом
> является
Вот я специально именно MSSQL в пример привёл. Там - является. А вторичный - не является индексом, только кандидатом на индекс.
> Кластерный индекс по GUIDу -- это ад и израиль.
Не, для GUID - ничего страшного, 16 байт.
← →
Дмитрий Тимохов (2011-02-03 18:01) [48]Мы программу правим.
Все история остается в SVN.
← →
boriskb © (2011-02-03 18:05) [49]
> Интересна именно практика, какие решения вами (вашими знакомыми/незнакомыми)
> использовались в проектах
Сильно уж зависит от предметной области.
Пытался улавливать "структуры" и их формализовать.
Ну не совсем же уж от фоноря они новые расчетные схемы придумывают.
Всё равно в каких-то рамках. Вот эти рамки и искал. Вместе с заказчиком естественно.
А дальше, никуда не денешься - "метаязык", но он совсем не сложный становится, если удаётся правильно уловить/установить рамки
← →
DiamondShark © (2011-02-03 19:05) [50]
> Ega23 © (03.02.11 17:49) [47]
Первичный ключ кластерный если явно не указано NONCLUSTERED и нет других кластерных ключей и индексов.
Но может быть некластерным при явном указании.
Кластерный индекс по GUID страшен не размером, а порядком сортировки.
← →
Ega23 © (2011-02-03 19:42) [51]
> Но может быть некластерным при явном указании.
Да? Ну фиг знает, может и так. BOL под рукой нет, да и с сиквелом уже давно дела не имел. Возможно, спорить не буду.
> Кластерный индекс по GUID страшен не размером, а порядком
> сортировки.
А тебе не всё равно, в каком оно порядке индексируется "где-то-там-в-недрах"?
Мне сложно представить, когда нужно сортировать по GUID-у.
Впрочем, точно также сложно представить, когда надо по первичному (физическому) ключу сортировать. Обычно по названию, ну там дате, ещё какой-нибудь фигне. Я в справочных таблицах частенько int-поле сортировки закладывал, чтобы пользователь сам мог настроить порядок вывода записей. Например, те, которые чаще всего используются - в начале выборки.
Хотя, если честно, я всего 1 раз GUID первичным ключом делал. Но там действительно без этого было бы крайне тяжко, ибо нет в MSSQL сиквенсов.
← →
DiamondShark © (2011-02-03 20:20) [52]
> Ega23 © (03.02.11 19:42) [51]
При хранении и выборках пофиг. Но:
> The pages in the data chain and the rows in them are ordered
> on the value of the clustered index key. All inserts are
> made at the point where the key value in the inserted row
> fits in the ordering sequence among existing rows.
Улавливаешь, что будет происходить при вставках хаотических значений ключа кластерного индекса?
← →
MsGuns © (2011-02-03 20:24) [53]>DiamondShark © (03.02.11 16:56) [39]
>> С ростом библиотеки шагов программист становится нужен все меньше и меньше.
>А кликающий настройщик плавно превращается в программиста на вновь >зародившемся DSL. И круг повторяется.
Верно подмечено :)
← →
MsGuns © (2011-02-03 20:37) [54]Из собственного опыта:
Всего существует не так уж много путей "универсализации".
Путь 1. "Купить готовое"
Навроде упомянутой здесь действительно мощной системы типа SAP-R3
Но помимо денюх, мороки с настройкой и т.д. нет никакой гарантии, что
А) Все проблемы реально решатся, а не перейдут на новый уровень
Б) Внедрение и сопровождение не потянет за собой куда большие затраты, чем замененная "ручная", к тому же усугубится пресловутой кадровой проблемой
В) Вообще система "натянется" на реальные условия
Путь 2. "Заказать готовое"
В какой-то мере общится с 1), но иногда реально помогает.
Минусы тоже очевидны - не имеет смысла перечислять.
Путь 3. "Придумать свое"
В принципе самый "правильный" способ хотя бы потому, что все в твоих руках. Однако чтобы заниматься подобными на сложных ОА (объектах автоматизации), надо иметь достаточно хорошие гарантии со стороны работодателя: как в финансовом, так и во временном отношении.
К тому же самый рИсковый путь, где гарантия, что ГИПу не осточертеет бороться с постоянно возникающими проблемами, что у него хватит мозгов, что его коллег хватит мозгов, что хватит мозгов у руководства все это терпеть и т.д.
И все-таки, ИМХО, путь 3 самый интересный (для меня во всяком случае :)
И если итти все же им, то надо сразу определиться с базовыми вещами (самое трудное) - КТО будет пользоваться системой, ЗАЧЕМ и ЧЕМ готов пожертвовать.
← →
MsGuns © (2011-02-03 20:43) [55]Мне доводилось работать на всех 3-уровнях (уровень монстра типа САП-Р3,- "Парус" в большой корпорации, прохожу в настоящее время Э<8:o).
Каждый по-своему интересен и полезен. Все зависит опять же от предметной области и объекта автоматизации.
← →
12 © (2011-02-04 08:49) [56]
> Ega23 © (03.02.11 19:42) [51]
такое может еще случится, когда сменили PK и вообще стали явно колдовать над индексами, "повышая производительность"
Вот потом точно - ад и израиль :)
← →
Константинов (2011-02-06 01:39) [57]И все-таки я не до конца понял что имеется ввиду. Построение математической модели бизнес-процесса? Или обработка конкретной информации (например финансовой) из конкретных БД, для последующего анализа менеджером?
Если первое, то я поступал так (не как программист, а как "аналитик"):
а) определял какие факторы значимы для бизнес-процесса (на первом этапе это можно сделать грубо)
б) считал динамику изменений каждого фактора на протяжении достаточно длительного периода
в) смотрел динамику действий конкурентов на данном направлении
г) Складывал полученные значения, получая грубую бизнес-модель.
Если не вписывался в расчетные значения прибыли начинал модель "дотачивать напильником", желая получить приемлемые цифры.
Если второе (и речь идет об оптимизации существующего бизнес-процесса)
на мой взгляд в программе нужно учитывать только те факторы, которые поддаются учету (уже учтены) и она должна уметь делать выборки из существующих БД.
Тут много засад. Бизнес-процесс всегда сильно зависит от внешних факторов (действия конкурентов, колебания курсов валют, текучки кадров и т.п.)
поэтому выборки из БД дают лишь часть необходимой информации для принятия решений... очень многие факторы влияют на результат не явно или имеют разный эффект на разных по продолжительности отрезках времени. пример: оператор связи, эксплуатируется сеть. Операционные затраты ххх руб. 30% от затрат - ФОТ персонала.
В краткосрочной перспективе, ФОТ можно соптимизировать до 0% и результат (количество проданного трафика почти не изменится), в долгосрочной перспективе, когда потребуется серьезный апгрейд сети или когда конкуренты начну массово внедрять доп. услуги - эта статья затрат станет критичной. Доходы начнут снижаться прямо пропорционально "неудовлетворенности" пользователей предоставляемыми услугами. Как посчитать эту "неудовлетворенность"? Никак. Можно только оценить по косвенным признакам (количество расторгнутых договоров).... Значимый фактор остается за бортом мат. модели бизнес-процесса.
вычислить, как наиболее эффективно построить бизнес-процесс, это даже не наука, это талант, который дан далеко не каждому менеджеру.
Вобщем, как мне кажется, бизнес-планирование процесс больше эмпирический, чем расчетный. Всегда должны быть "запасы" ресурсов чтобы где нужно добавить, где нужно сократить и перераспределить.
← →
Игорь Шевченко © (2011-02-06 01:46) [58]Константинов (06.02.11 01:39) [57]
> И все-таки я не до конца понял что имеется ввиду
имеется в виду учет изменений деталей бизнес-процессов в приложениях. Не построение, не оптимизация, не советы о том, как построить, а учитывать разнообразные варианты условий и их комбинации.
← →
Mike_Goblin (2011-02-07 14:38) [59]Добрый день, Игорь
Прочитал ветку, сложилось впечатление, что ты ищешь либо решения из области BPM (Business process management), либо из смежной с ней области Rule based engine.
В любом случае, посмотри на Drools http://www.jboss.org/drools.
Не интегрируешь с Delphi, так обогатишься идеями.
Если предлагаемое направление раздумий ведет совсем не туда, попробуй еще раз уточнить или переформулировать требования.
← →
Игорь Шевченко © (2011-02-07 16:15) [60]Mike_Goblin (07.02.11 14:38) [59]
Добрый день, Михаил,
Скорее из области Rule based engine. За ссылку спасибо, для интеграции с существующими приложениями на первый взгляд слишком мощно :)
← →
b z (2011-02-07 17:05) [61]
> И все-таки я не до конца понял что имеется ввиду.
Ну тогда в N-ий раз расскажите свою историю, может ктото и "клюнет"...
← →
ZeroDivide © (2011-02-08 08:46) [62]Чтобы не трогать прогу, мы сделали изменяющиеся со временем расчеты на скриптах, с поддержкой версионности, т.е. можно сделать расчет по алгоритмам, актуальным на определенную дату. Ну и для юзеров "построитель запросов", квери билдер, так сказать...
Страницы: 1 2 вся ветка
Форум: "Прочее";
Текущий архив: 2011.05.22;
Скачать: [xml.tar.bz2];
Память: 0.67 MB
Время: 0.005 c