простые вопросы по Ораклу

[zVlad]

Посмотрел Вашу модель, не вдаваясь в детали заметил approver1, approver2, .... - очень не красивое и неправильное решение. А если понадобится пятый?, а где будете хранить информацию типа как в итоге отреагировал Approver? Это нарушение правила рарешения многие-к-одному. Должна быть создана таблица для многих.

Я знаю. И тоже до хрипоты спорила с юзерами, что так не надо. Но они упираются до последнего, что у них 4 апрувала и точка. Это-де кровью записано в ChangeManagement procedure. Впрочем вы правы, сделаю-ка я one-to-many и по поводу approvers. Там у них 3 отдела и над ними сидит один директор. То есть директор + 3 менеджера - approval commitee для всех запросов. Иногда если кто-то из них отсутствуют, они могут назначать proxy для approval и proxy не обязательно является юзером системы
Ну и еще для особо срочных requests достачтоно 2 approval-а, а не все 4.

Поправила схему вот так. Получилось даже лучше, потому что теперь и proxy и comments можно просто в эту таблицу Approvals засадить.

Сабина

Так это у Вас не учебный проект Так ведь уже такие системы давно существуют. Remedy Со., например, продукт. А юзеров надо держать подальше от того, что является предметом вашей ответственности. Эти же юзеры, с наглой рожей придут и скажут, а нам мол нужен теперь пятый или что-нибудь еще в этом роде.

[zVlad]

Она самая. В то время как на западе было одно лишь TSO, наши умельцы наделали разные Primus, OKO, Jack, Jessy и т.д.

работала я на этом чуде
До сих пор не понимаю, как можно было мириться с тем, что EC-1066 висела почти каждый день по 6 часов

...

Если мирились значит можно было. Я лично видел много случаев когда ЕС работали очень даже надежно. Например, на ЖД-ых ВЦ пятьнадцать (как помнится) минут простоя считалось ЧП и делался доклад начальнику дороги. А начальник, как я понимаю, автоматом бы подписывал приказ об увольнении начальника ВЦ. Что-то я не помню чтобы там хоть раз начальника ВЦ уволили. Хотя конечно и случаев ужасной работы ЕС-ок было немало.

[Lazy44]

... но точно это было в Примусе.

Рильке

[Sabina]

Так это у Вас не учебный проект Так ведь уже такие системы давно существуют. Remedy Со., например, продукт. А юзеров надо держать подальше от того, что является предметом вашей ответственности. Эти же юзеры, с наглой рожей придут и скажут, а нам мол нужен теперь пятый или что-нибудь еще в этом роде.

Учебный, но делаю я его под конкретную заинтересованную сторону. То есть моя выгода такая: если сделаю что толковое, то а) сама научусь, б) если им понравится, то может на работу возьмут.
Про Ремеди знаю, даже работала там. Они хотят 30 штук с этой конкретной фирмы, и их жаба душит. Для них это большой expense, а change management уже хочется автоматизировать.
Я даже нашла open source Zentrack (php) и им показала, но они говорят, если я сделаю именно под их workflow и JSP, то они лучше подождут мое.

Сабина

[JustMax]

Честно говоря, у меня получается в два раза меньше таблиц user, request, department, approvals . Все! usertype, userstatus, requestpriority под вопросом, а именно : если только значения в них НЕ являются статическими т.е. заранее не известны или очень volаtile. Иначе обходимся check constraint с перечислением значений. Еще совет - дабы автоматизировать approved бизнес правило, можно на таблицу approvals навесить table level триггер, где проверять количество аппрувалов и, если их количество достигает заданного, менять в таблице request approved статус на true. Я уже говорил: не плодите сущности без надобности!
IMHO!

[zVlad]

Так это у Вас не учебный проект Так ведь уже такие системы давно существуют. Remedy Со., например, продукт. А юзеров надо держать подальше от того, что является предметом вашей ответственности. Эти же юзеры, с наглой рожей придут и скажут, а нам мол нужен теперь пятый или что-нибудь еще в этом роде.

Учебный, но делаю я его под конкретную заинтересованную сторону. То есть моя выгода такая: если сделаю что толковое, то а) сама научусь, б) если им понравится, то может на работу возьмут.
Про Ремеди знаю, даже работала там. Они хотят 30 штук с этой конкретной фирмы, и их жаба душит. Для них это большой expense, а change management уже хочется автоматизировать.
Я даже нашла open source Zentrack (php) и им показала, но они говорят, если я сделаю именно под их workflow и JSP, то они лучше подождут мое.

Сабина

Я честно говоря не очень догоняю в плане какая от этого Ремеди польза то ожидается (кроме конечно доходов самого Ремеди, и чувства гордости за то что еще одна сфера человеческой деятельности автоматизированна).
Вот у нас Ремеди. Лично для себя я вижу пользу в том, что когда нужно что-то сделать, что уже делалось раньше то можно воспользоваться. Но я это и без Ремеди могу организовать.
У кого-нибудь есть пример действительно делового применения Ремеди от которого что-то было получено такое, чего другими средствами бы не добыть никак?

Неужели та контора, Сабина, не понимает что того что предлагает Ремеди за 30 штук, получить за меньше просто не возможно. За меньше можно получить что-нибудь более (и очень даже) простое. А самое главное, кто будет сопровождать после успешного вредрения? Только Вы, Сабина, им об этом не говорите. В Ваших интересах, чтобы они и дальше заблуждались, и в конце концов купили Ремеди, а Вас бы наняли за этим Ремеди присматривать.

[Sabina]

Честно говоря, у меня получается в два раза меньше таблиц user, request, department, approvals . Все! usertype, userstatus, requestpriority под вопросом, а именно : если только значения в них НЕ являются статическими т.е. заранее не известны или очень volаtile. Иначе обходимся check constraint с перечислением значений. Еще совет - дабы автоматизировать approved бизнес правило, можно на таблицу approvals навесить table level триггер, где проверять количество аппрувалов и, если их количество достигает заданного, менять в таблице request approved статус на true. Я уже говорил: не плодите сущности без надобности!
IMHO!

status, type, department. etc. выделены в отдельные таблицы, потому что как вы справедливо заметили, могут в любой день добавить департмент или разбить одни на два. То же со стастусом юзера, пока очень простенько, но возможно придется поменять/добавить.

триггер на таблицу как средство отслеживания статуса не пойдет, там очень много у них этих статусов, вообще сам workflow очень сложный. Если один из approver-ов делает correctioins ли в принципе возражает, это все идет обратно к submitter, или там QA недоволен. Короче делалось с учетом всех этих прибамбасов.

Сабина

[Sabina]

Я честно говоря не очень догоняю в плане какая от этого Ремеди польза то ожидается (кроме конечно доходов самого Ремеди, и чувства гордости за то что еще одна сфера человеческой деятельности автоматизированна).
Вот у нас Ремеди. Лично для себя я вижу пользу в том, что когда нужно что-то сделать, что уже делалось раньше то можно воспользоваться. Но я это и без Ремеди могу организовать.
У кого-нибудь есть пример действительно делового применения Ремеди от которого что-то было получено такое, чего другими средствами бы не добыть никак?

По этому поводу вот что могу сказать... Одно из их преимуществ - это все интегрированно (help desk, change management, remedy web...).

Когда эта фирма проводила research - Remedy's Change Management оказался одним из наиболее близких к их Workflow алгоритмов. Я думаю Remedy достаточно оптимальна для крупных фирм, там среди заказчиков и Boeing, Walmart, Lockheed Martin, Livermore Lab ....
Для них 30 штук - нормальный расход. Мелким же компаниям это невыгодно.

Сам по себе продукт мне не очень нравился когда я там работала. Даже в самой старой ARS и то баг выскакивал то тут то там. А уж сколько от заказчиков наслушалась. Но факт налицо - берут их продукт.
У меня и сейчас там трое знакомых работает ( они теперь BMC company) и по их словам дела в фирме идут очень хорошо. Правда продукт они поругивают, по крайней мере тот из знакомых, что в tech support сидит.

Неужели та контора, Сабина, не понимает что того что предлагает Ремеди за 30 штук, получить за меньше просто не возможно. За меньше можно получить что-нибудь более (и очень даже) простое. А самое главное, кто будет сопровождать после успешного вредрения? Только Вы, Сабина, им об этом не говорите. В Ваших интересах, чтобы они и дальше заблуждались, и в конце концов купили Ремеди, а Вас бы наняли за этим Ремеди присматривать.

Они не будут покупать Ремеди однозначно. И сопровождать некому и в бюджет не влазит, и пока они ведут Change Management на бумаге и никто от этого не умер. И самое главное сопровождать Remedy - это последнее, чем я хотела бы заниматься. У меня к ним личные счеты. Меня оттуда вынудили уйти потому что я срочно уехала на 3 недели в Россию к папе, который перенес инфаркт. Сначала сказали ОК - езжай. А потом в самый день перед вылетом, вызывает меня к себе менеджерша и предупреждает, что у меня всего 2 недели отпуска. А у меня уже билеты куплены и т.д. А вопрос был поставлен четко: или я сама ухожу или они меня по приезду обратно увольняют. Я конечно сама ушла, тем более что натерпелась я там немало и уже к тому моменту сама хтела уходить. Но дело было не в компании, а в team lead. Она меня просто органически возненавидела с первого дня. И поэтому несмотря на excellent performance и customer awards, меня оттуда вот таким вот образом поперли (менеджерша с team lead все время ходили парой). Сорри за личное в таком разделе, но вот накатило...

Насчет сопровождения, это тоже недешевое удовольствие. Эта маленькая фирма нашла мужика, который вызвался поставить Help Desk за 35 в час, но он плохо знал Юникс и в итоге ничего на их конфигурацию посадить не смог.
Потом они нашли ребят из Ремеди (моих знакомых) за двойную стоимость, которых им пришлось долго уламывать, ибо те по контракту не имеют право работать на стороне.
В общем не дозрели они поиметь такой же тройной геморрой еще и с Change Management.

Сабина

[Sabina]

.... Еще совет - дабы автоматизировать approved бизнес правило, можно на таблицу approvals навесить table level триггер, где проверять количество аппрувалов и, если их количество достигает заданного, менять в таблице request approved статус на true.

Кстати триггеры будут на тот же статус и будут email notifications во все стороны после смены статуса. Но полностью переложить смену статуса на триггер невозможно. Скажем первый approver сделал поправки, тогда все это идет rolled back to submitter, если он не сделал поправку- сопоставляется с тем что сказали остальные три. Потом QA может развернуть. Такое нерационально все на триггеры возлагать (ИМХО!).

Сабина

[JustMax]

.... Еще совет - дабы автоматизировать approved бизнес правило, можно на таблицу approvals навесить table level триггер, где проверять количество аппрувалов и, если их количество достигает заданного, менять в таблице request approved статус на true.

Кстати триггеры будут на тот же статус и будут email notifications во все стороны после смены статуса. Но полностью переложить смену статуса на триггер невозможно. Скажем первый approver сделал поправки, тогда все это идет rolled back to submitter, если он не сделал поправку- сопоставляется с тем что сказали остальные три. Потом QA может развернуть. Такое нерационально все на триггеры возлагать (ИМХО!).

Сабина

Отчего ж . На триггеры прекрасно все ложится. Строится конечный автомат. Состояния, значения полей (must be, may be, must not be) , возможные переходы между состояниями при update, insert, delete накладывается на матрицу (отдельная таблица) и вуаля. В триггере ноль бизнес логики - он только накладывает изменения данных на матрицу и выполняет откат если состояние запрещено или возможный вызов процедур если таковые для данного события/перехода/состояния определены в матрице. При особенно сложной логике приложений только так и спасаемся. Пример - кредитный договор в банковской системе со всеми сложными состояниями присущими таким обьектам. Прикажете мне все в клиенте проверять (win, bean, web, appserver whatever) ? Мое глубокое IMHO - зная и используя возможности развитых баз данных хотя бы на 20-30% (не для написания business logic а только для поддержания business integrity) можно избежать написания тонны "бизнес логики" на любом клиенте.

[Sabina]

На триггеры прекрасно все ложится. Строится конечный автомат. Состояния, значения полей (must be, may be, must not be) , возможные переходы между состояниями при update, insert, delete накладывается на матрицу (отдельная таблица) и вуаля. В триггере ноль бизнес логики - он только накладывает изменения данных на матрицу и выполняет откат если состояние запрещено или возможный вызов процедур если таковые для данного события/перехода/состояния определены в матрице. При особенно сложной логике приложений только так и спасаемся.

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

Сабина

PS. JustMax, вы у меня первый в списке кандидатов в приемочную комиссию по этому приложению, так что к началу июня готовьтесь (Just kidding )

[Sabina]

все-таки вопрос с encoding.
сделала

SELECT *
FROM nls_database_parameters
WHERE parameter = 'NLS_CHARACTERSET';

Oracle (data150) says:
PARAMETER VALUE
------------------------------ ------------
NLS_CHARACTERSET WE8MSWIN1252

Получается мом данные в Windows -1252.
А вот тутвон что написано:

There are of course, many other character encodings in general use, the most common on Windows platforms being Windows 1252. Many programs assume that 1252 is the same as ISO-8859-1 but it is not, 1252 defines an extra 34 characters in addition to those from ISO-8859-1. If there is a possibility that data will be used on other platforms, make sure that the program is really saving in ISO-8859-1 format and not Windows 1252.

То есть если я хочу, чтобы моя DB была portable, мне надо поменять кодировку?

Как это делают чтобы с самого начала кодировка была какая нужно? SQL командой в DBSchema или еще как?

Спасибо,
Сабина

[vc]

все-таки вопрос с encoding.
сделала

SELECT *
FROM nls_database_parameters
WHERE parameter = 'NLS_CHARACTERSET';

Oracle (data150) says:
PARAMETER VALUE
------------------------------ ------------
NLS_CHARACTERSET WE8MSWIN1252

Получается мом данные в Windows -1252.
А вот тутвон что написано:

There are of course, many other character encodings in general use, the most common on Windows platforms being Windows 1252. Many programs assume that 1252 is the same as ISO-8859-1 but it is not, 1252 defines an extra 34 characters in addition to those from ISO-8859-1. If there is a possibility that data will be used on other platforms, make sure that the program is really saving in ISO-8859-1 format and not Windows 1252.

То есть если я хочу, чтобы моя DB была portable, мне надо поменять кодировку?

Как это делают чтобы с самого начала кодировка была какая нужно? SQL командой в DBSchema или еще как?

Спасибо,
Сабина

The Oracle database has _two_ character sets: (1) the database character set and (2) the national character set.

(1) is used for:

o Data stored in SQL CHAR datatypes (CHAR, VARCHAR2, CLOB, and LONG)
o Identifiers such as table names, column names, and PL/SQL variables
o Entering and storing SQL and PL/SQL source code

(2) is an alternative character set that lets you store Unicode character data in a database that does not have a Unicode database character set.

The choice of both depends on your specific application(s) requirements.
(1) and (2) are defined during the database creation process (the CREATE DATABASE statement). Both can be changed with the ALTER DATABASE statements iff the new character set is a strict superset of the current character set.

For details, see http://download-west.oracle.com/docs/cd ... 29/toc.htm


VC

[Sabina]

For details, see http://download-west.oracle.com/docs/cd ... 29/toc.htm

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

В данный момент у меня в базе стоит charset WE8MSWIN1252.
Из приведенной мною статьи ясно, что мне нужно WE8MSWIN1252.

Правильно ли я поняла, что при создании базы мне нужно было указывать "WE8MSWIN1252"? На данной базе это не получится, я не администратор и доступа ни к чему нет. Но на будущее учту. То есть сама установка charset добавляется в create database statement.

А интересно как происходит конвертация, скажим если на webpage в метатаге стоит
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
Ведь в самом-то Оракле данные, набитые в полях форм уже в другой кодировке Windows-1252?

Сабина

[JustMax]

В данный момент у меня в базе стоит charset WE8MSWIN1252.
Из приведенной мною статьи ясно, что мне нужно WE8MSWIN1252.

А интересно как происходит конвертация, скажим если на webpage в метатаге стоит
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
Ведь в самом-то Оракле данные, набитые в полях форм уже в другой кодировке Windows-1252?

Сабина

Wo pervych opasaites' situacii kogda s klienta (browser) prihodiat dannye v kodirovke otlichnoj ot clienta bazy dannyh (WebServer, AppServer) - mozhet poluchitsia kasha. Esli klient bazy rabotaet v kodirovke WE8MSWIN1252 to i Content-Type dolzhen byt' MSWIN1252 vo izbezhanie. Esli zhe u vas i client bazy i udalennyj client (browser) rebotajut v kodirovke iso-8859-1 (Oracle WE8ISO8859P1) a baza sozdana s kodirovkoj WE8MSWIN1252 to Oracle delaet konvertaciju avtomaticheski mezhdu dvumia charsets. Pri etom esli v bazovoj kodirovke otsutstvujut nekotorye simvoly, to oni zameniajutsia na foneticheski blizkie (ä -> a, ü -> u) ili na simvol zameshenija (po umolchaniju '?'). Pri etom vazhno chtoby na kliente bazy (AppServer, WebServer) byla opisana peremennaja okruzhenija NLS_LANG (naprimer NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1), chtoby Oracle znal iz kakoj kodirovki nado delat' konvertaciju. V principe v vasem sluchae kodirovka klienta mozhet byt' kak ISO tak MSWIN t.k ISO8859-1 javliaetsia strong subset of MSWIN1252, t.e. vy ne budete imet' problem s perekodirovkoj (t.e. perekodirovki voobshe ne budet). V obshem sluchae esli perekodirovku mozhno izbezhat' - luchshe eto zdelat' hotia by radi performance. Voobshe esli hotite polnost'uj portable database, ispol'zujute dlia bazy kodirovku AL32UTF8 (Unicode 3.2) pri etom esli vy v osnovnom pol'zuetes' ASCII simvolami, to vy nichego ne proigraete - pod nich tak zhe kak i ran'she budet vydelen odin bait! . Esli zhe vy nachnete ispol'zovat' simvoly iz drugih (bolee rasshirennyh kodirovok) - pod takie simvoly budut vydeliatsi ot 2 do 4 bait (Napr pod nem. bukvy üßäö - 2 baita, pod kitaiskie, japonskie 3 baita, pod spec. simvoly 4 baita)