2012/8/19 Naim Shafiev <[email protected]>: > 17 августа 2012 г., 23:31 пользователь Ruslan Zakirov > <[email protected]> написал: >> 2012/8/17 Naim Shafiev <[email protected]>: >>> 17 августа 2012 г., 13:16 пользователь Sergey Malochinskiy >>> <[email protected]> написал: >>>> Мне не совсем понятно из вашего описания, что вы ждете от тикет >>>> системы. С упомянутыми вами продуктами не знаком и оценить возникшие >>> Синтегрировать все в одной системе.Эдакий монстр. >>> >>>> сложности по такому описанию не могу. >>>> Создавать тикеты(заявки через API) а работать сотрудникам через >>>> Web-интерфейс. Это основной путь интеграции. >>> >>> Я покамесь тоже только такой путь и вижу. >> >> Для интеграции все равно придется опрашивать стороннюю систему или >> тянуть данные. Так как везде perl, то RPC/REST можно не использовать, >> а использовать API. > > +1. Я из-за этого и выбираю между OTRS/RT. > >> >>> к примеру нельзя выбрать абонента у которого траблы, >> >> Вот для этого вам придется либо писать SQL, который говорит с >> несколькими БД, хранить все в одной БД и общаться с частью OTRS/RT на >> чистом SQL. Другой вариант написать скрипт, который в вашу БД заливает >> выжимки. Последнее считаю предпочтительней. Во первых, не нужно >> общаться с другой системой в реальном времени. Во вторых, систему >> легче заменить. > > Ок,логически я так себе все представлю. > Попробую реализовать оба варианта( и их по очереди запустить на части > абонентов в продакшене) > >> >> Самый простое - это флаг в таблице абонентов, который синкается с >> трекером. Можно соответственно делать простые запросы типа "найти >> абонента с проблемами". На странице абонента ссылка на трекер, которая >> ведет сразу на поиск активных заявок этого абонента. >> > > Ок. > >> Усложняется процедура поддержки и внесения нового функционала. > Где усложняется и почему? > Если ironleg то там усложнение будет минимально возможным .
Если тянуть данные в ironleg, то возникает вопрос сколько тянуть. Каждое изменение приведет к изменению в схеме, в скриптах, которые тянут и так далее. Если брать в реальном времени через API, то самые большие трудности с кросс выборками. Несколько способов: 1) Вы можете делать их через программный nested loop - для каждого найденого объекта одной БД делаем проверку в другой БД. Медленно и не эффективно. Можно ускорить проверкой сразу нескольких найденных записей. Хорош вариант завязкой только на API. 2) Как я уже говорил, можно в одну из систем внести знания о схеме БД другой системы. Тогда можно делать выборки из двух БД сразу используя API одной системы. Недостаток в привязке к схеме БД, а также в необходимости понимать ее. Схема БД редко описывается. Изменения между мажорными версиями, если они есть, то они часто радикальные. > P.S > Я щас немного не сразу вьезжаю наверное из-за воздуха Лерика ;) -- Best regards, Ruslan. -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
