Прочитал топик >> Про бизнес логику , и у меня возник вопрос, А что это такое и с чем его едят.

1.) Что такое бизнес логика в терминах MS SQL Server-a.
короче что под этим понимает Microsoft
2.) Где и как она описывается в MS SQL Server.
3.) Ресурсы, ссылки, где про это можно прочитать.
Спасибо.

Почему меня это заинтересовало:
у меня на предприятии существует система (Access+MS SQLServer+ODBC), которая начинала разрабатыватся еще в лахматых годах, и совершенно другими программистами. Не описания, ни вообще какой бы то нибыло документации нет.

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

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

Короче хотелось бы иметь систему описывающую процессы предприятия, а документы, начальники, подчиненные, и т.п. как производное от этих процесов.
А сейчас имеется описанный в системе документо оборот, причем описан так, что изменения весьма трудоемки.
И еще я хотел бы это делать плавно, не останавливая работы отделов в связи с "ремонтом" :)

Спасибо всем кто откликнулся.

Спасибо за ответ.

ASCRUS 1. Бизнес-логика на СУБД - это код, выполняющий действия по ТЗ (расчеты, проверки, действия на события и т.д.) и лежащий в самой БД.
2. Хранимые процедуры, триггеры, вьюверы, правила, констрайнты и т.д.

Все оказалось немного бональнее чем я думал.

А я то губки раскатал, думал что что нить наподобии Rational Rouse только по проще...

Dik76Бизнес логика закладывается с помощью правил ограничения ссылочной целостности, хранимых процедур, тригеров, ограничений (constraint). Рой в этом направлении.

Уже... , просто я думал это нечто другое, Белое и пушистое

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

И еще, хотелось бы услышать мнения, соображения и т.п. по поводу
автор
Почему меня это заинтересовало:
у меня на предприятии существует система (Access+MS SQLServer+ODBC), которая начинала разрабатыватся еще в лахматых годах, и совершенно другими программистами. Не описания, ни вообще какой бы то нибыло документации нет.

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

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

Короче хотелось бы иметь систему описывающую процессы предприятия, а документы, начальники, подчиненные, и т.п. как производное от этих процесов.
А сейчас имеется описанный в системе документо оборот, причем описан так, что изменения весьма трудоемки.
И еще я хотел бы это делать плавно, не останавливая работы отделов в связи с "ремонтом" :)

Спасибо всем кто откликнулся.

Короче мне надо осуществлять и проводить в жизнь изменения, причем делать это плавно, и так, чтоб после меня другой програмист не повесился, а спокойно продолжал работу (ну на случай, ну мало ли ... )

Еще раз спасибо всем кто откликнулся.

Буба Касторский А мне бы хотелось, чтобы мой босс приходил на работу в гавайских шортах - веселее было бы. Не ему этого не очент-то хочется.
Если ваша "логика от документа" появилась в доисторические времена, и до сих пор "работает", то что дает Вам основание думать, что Вашему руководству также понравится Ваша идея о переходе к процессной парадигме?
Моему руковдству нужно только одно - рабочая система, и точка.

А мои пользователи работают в этои системе - как по минному полю ходят.
Я не хочу и не собираюсь ругать того кто работал до меня, просто на данный момент существует такая ситуация. Моих ресурсов хватает, чтоб исправлять экстренные ошибки, и чуть чуть работая на упреждение исключать те ошибки, которые еще не выплыли в отчетный период.
Так вот, поскольку уменя не смотря не на что, все же получается работа на упреждение, и некоторые шаги по оптимизации уже сделаны И УСПЕШНО! я ищу направление, в котором можно двигатся далее. Ведь НЕТ ПРЕДЕЛА СОВЕРШЕНСТВУ и к этому надо стремится


Буба Касторский авторИ еще я хотел бы это делать плавно, не останавливая работы отделов в связи с "ремонтом" :)

Утопия.

Ну я же уже вношу изменения, и еще не утонул...
Телефон, телевизор, полетны в космос - это тоже утопия... была.


Еще мнения? буду признателен :)

ASCRUS Если правильно под задачу выбрана СУБД и клиентская часть, если граммотно спроектированна БД и с продуманным использованием наследования написана клиентская часть, то это подойдет под утверждение:
автор
Короче мне надо осуществлять и проводить в жизнь изменения, причем делать это плавно, и так, чтоб после меня другой програмист не повесился, а спокойно продолжал работу (ну на случай, ну мало ли ... )


Вы же, насколько я понял, ищете не решение, а инструмент. На этому форуме обсуждались такие инструменты (ОО настройки над РСУБД, 3-х звенки и т.д.). Лично мое отношение к ним отрицательное из за одной известной аксиомы "Чем больше кода, тем больше ошибок". Но это только мое личное мнение :)

Дело в том что СУБД уже выбрана, клиент уже написан...
Все это работает... с ошибками...
и я как программист, который сопровождает эту ситсему, прилагаю усилия к тому, чтоб со временем эта ситсема стала более сопровождаемая, и естествено убираю ошибки (опять же допускаю новые, так же убираю ) ну и т.д.
Высказывались мнения что плавный перевод ситсемы невозможен, возможен...
если осторожно. (и вода камень точит)
Система была написана и заточена под 97 Access, уже сейчас переведена на 2000, ликведированы многие ошибки, увеличено быстродействие кретических узлов.
Планирую дальнейший перевод на ADP, пока веду подготовку, переписываю куски на с DAO ADO.
И у меня появилась понимание того что именно сейчас, когда я переписывая какие то куски глубоко вникаю в бизнес, наиболее удобный момент, для того чтоб начать описывть, документировать систему, и планировать ее "итоговый" вариант. Слово итоговый взято в ковыки, т.к. нет предела совершенству

ASCRUS Вы же, насколько я понял, ищете не решение, а инструмент.
Да я ищу инструмент, да я рассматриваю различные варианры решений.
Но главные задачи которые стоят (в порядке убывания важности):
- Работоспособность системы
(все серьезные изменения перед введением качественно тестируются, и
остовляется возможность быстрого отката в случае проблем)
- Оперативное внесение новых возникающих требований
- Повышение юзабилити клиента
- Документирование системы (которого нет)
Если былабы система, которая держала актуальной связку
модель <==> база, то было бы класно.
- Структурное оптимизирование системы

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

В споре рождается истина...

авторЕсли же фирма крупная, то проект без серьезной поддержки собственников и не поднять
Да фирма крупная, и не называю ее я не спроста, а потому что "рекомендовали" не светится.
А по поводу
авторбез серьезной поддержки собственников и не поднять
тоже согласен, ну блин если было бы все так просто в этом мире, ну к сожалению нет в реальной жизни черного и белого. Есть и стремления в определенной степени, и тормоза тоже присутствуют. Одним словом политика,
в котороую у меня нет совсем желания влезать...
А есть желание у меня ДЕЛАТЬ КАЧЕСТВЕННЫЙ ПРОДУКТ и ОПЫТ... ГЛАВНОЕ ОПЫТ

Всем спасибо, буду рад услышать еще мнения...

авторДля того, что бы познакомиться с методиками описания БП, я и привел ссылку на www.vernikov.ru
За ссылку на Верника огромное спасибо.
Кончечно осуществлять рекомендации по образу
как описано в этой статье , мне ни кто не даст, НО
опять же хочу оговорится если есть цель, и есть непреодолимое препятствие в данный момент, то это совсем не значит что цель не достижима в принципе!
Поэтому работаем в предположении, что может быть у нас получится дойти до этой цели (опять же может быть у нас, может быть получится дойти ).

Я конечно не такой оптимист, как может показатся, и ...
короче есть задача - работаем, стараемся работать эффективно, болше головой, меньше руками :)

авторПоэтому, как мне кажется, soldatу все равно придется, хотя бы для себя,
набросать (эх, легко говорить....) модель БП as is.
Правильно кажется, мне тоже так кажется
Работаем в этом направлении...

avlihХотелось бы также узнать роль soldat на этом предприятии. Может он чуть -чуть генерал.:)
не а, я рядовой...

Не знаю на сколько это интересно, но пришли к такому решению:
Создаем базу, по мере въезда в производственные процессы, в ней создается
оптимизированная структура, та часть которую она закрывает в старой базе View-хами перелинковывается на новую базу, старая АККУРАТНО убивается (с каччественными бэкапами и т.п.) а клиент потихоньку переписывается под новую структуру. Это хоть как то позволит сдвинутся с мертвой точки и даст возможность изменять (хоть и медленно) существующую структуру базы... двигаясь в направлении оптимальной структуры.

Собственно с этих идей и начались мои вопросы (глупые или нет вам судить) по поводу бизнес логики case средств и всего остального.

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

avlih Если существующая система устраивает всех пользователей, кроме программиста (и главное, собственник не выделяет ресурсы на ее замену), то единственный выход: расслабиться и не стараться переделать мир по себя.
Еще остается самообразование, повышение квалификации, и постоянное приобретение навыка ЭФФЕКТИВНОЙ производственной деятельности.
Я думаю avlih со мной согласится, что поставленную задачу можно решать по разному, и разными ресурсами.
У меня есть простая задача поддержание работоспособности старой системы, не более... А все то что я сдесь рассказываю, это пере-постановка задачи со своей точки зрения. И я хочу сказать, что пока работы себе я не увеличил, а наоборот уменьшил. Те действия которые проводились, привели к тому, что непосредственной беготни по пользователям стало меньше, и в критические отчетные дни стало выделятся меньше крови программистов.