Comments 28
Хранение файлов в БД так себе решение...
А зачем уж так сильно дробить таблицу Ticket, выносить в отдельные таблицы справочники информацию?
На самом деле там Таблица статусов выглядит лишней (можно enum применить), да между Task_tiket надо вставить таблицу развязку (связь многие ко многим), а остальное нормально.
Про файлы в БД - в данном случае это выглядит удобнее, нежели чем возня с файловой системой (головная боль от бакапов, протухших ссылок на файлы и пр.), разумеется размеры файлов надо ограничивать.
По первому вопросу, в базе хранятся только ссылки на файлы, сами файлы загружаются в папку media/numberTicket
По поводу отдельных справочников, мне показалось это достаточно разумно, вынести в отдельные таблицы информацию, которая не меняется от тикета к тикету, а просто берется из справочников. И как мне кажется, так проще и удобней делать выборку. Буду рад услышать как это сделать правильней.
Все правильно. Одно из важнейших правил нормализации, все что дублируется и можно объединить в некий "справочник" - должно быть в отдельной таблице.
Я бы посоветовал использовать minio для хранения файлов, если хочется иметь автономию и не прибивать себя к azure / amazon. Таким образом ты получишь надёжное распределенной хранилище. Доступ к нему можно сделать публичным при необходимости
Странное решение - запрещать пользователям оставлять заявки через почту. Ведь можно выделить для хелпдеска отдельный ящик, и настроить парсинг писем из этого ящика в хелпдеск.
Люди гораздо охотнее пользуются сервисами, которые заставляют минимально корректировать их жизненные привычки. Да, это добавляет необходимость операции классификации заявки для назначения на нужную группу, но для процесса гораздо важнее получить заявку в систему пусть даже в не полностью готовом виде, чем провоцировать пользователя использовать не регламентированные каналы связи с техническим департаментом.
На самом деле даже в приеме звонков по телефону нет ничего плохого (ведь пользователь не может попасть в хелпдеск если у него не включается ПК или перестало работать сетевое соединение) - просто необходимо выделить одного оператора, который должен заниматься только регистрацией и классификацией заявок. Да, это накладные расходы, но это значительно повышает приживаемость системы в эксплуатации: сервис деск это в первую очередь инструмент повышения качества обслуживания для IT отдела. Доя пользователя его выгода не очевидна, и чем меньше он контактирует с системой, тем ему удобнее.
Я понимаю, что статья не столько про сервсис-деск, сколько про факт использования новых навыков, но проектирование бизнес-процессов моя профессиональная область и не смог пройти мимо очевидных ошибок новичка)
Вообще, если планируете развивать свой сервис, рекомендую почитать/посмотреть про процесс управления инцидентами в библиотеке ITIL(желательно версии 3 или 4). Хотя бы беглое знакомство с ним позволит избежать детских ошибок в покорении вершин становления хелпдеска.
Правильно организованный хелпдеск, при должной квалификации инженеров позволяет вдесятером обслуживать компанию размером в 2-3 тысячи пользователей.
а можно посмотреть код проекта?
К сожалению, код проекта в том виде в котором описан в статье не сохранился. Многое уже переделано.
Для ознакомления подойдут, например, ранние коммиты. А, в принципе, особой разницы то нет, современную версию тоже интересно увидеть. Всегда полезно знать, как такой вопрос другие разработчики решают на Django.
Я бы все же переопределил модель пользователя, для работы с одной моделью пользователя а не двумя. Ну и тикет и коммент это же одна и та же модель через foreign(self). у меня это сделано так.
Ранних коммитов не было, всё делалось локально. Возможно напишу статью про то что есть сейчас, с кодом.
Модель пользователя - таблица Account расширяет стандартную модель Django User через поле OneToOneField.
Ticket и Comment это две разные таблицы. Comment связан и с Ticket, и с User, через ForeignKey. То есть у одной заявки может быть много комментариев от разных пользователей. У меня это сделано так.
Я имел ввиду, что Можно поменять модель пользователя и избавиться от двух таблиц и одной o2o.
По поводу таблиц "тикет-комментарий" смотри: поля дублируются, было б неплохо в комментарии тоже иметь дату и т.п. Если сделать только одну таблицу "тикеты" с parent=ForeignKey('self'), то, в итоге, любой комментарий - это тот же тикет, правда с заполненным полем "родитель". При этой структуре родитель-ребенок можно комментировать не только тикеты но и комментарии, которые тоже суть есть тикеты. Юзер у каждого тикета(комментария) свой. Кроме масштабируемой, хоть и рекурсивной структуры, становится проще поиск.
Понял что вы имеете в виду.
По поводу модели пользователя, дополнительные поля были добавлены позже, поэтому было решено делать так как проще, то есть создать ещё одну таблицу и соответственно связь o2o. В следующих проектах, конечно же буду сразу делать кастомную модель пользователя.
По поводу таблиц "тикет-комментарий", даже не подумал что можно сделать так как вы предлагаете. Для меня логичнее было создать отдельную таблицу, но ваш вариант, тоже вариант )
Пожалуйста, не надо так.
Тикет и комментарий - это разные сущности, и жить они должны отдельно. Даже не смотря на часть"похожих" полей, которые, на самом деле, описывают разные вещи.
В Django ticket и comment организуются через proxy модели, потому это разные сущности, со своими методами.
Хотя вопрос остается. @kit_oz А чем таким они разные, если они просто частички обсуждения одной темы?
Тикет - объект, обозначающий некий запрос от потребителя к исполнителю: сломался компьютер, создайте учётку. Каждый объект - самостоятельная сущность, не нуждающаяся ни в чём извне.
Комментарий - просто какой-то текст, относящийся к тому, к чему данный комментарий прикреплён, будь то тикет, чат или статья на Хабре, которую мы комментирует (представляете, Хабр хранил бы комментарии в одной таблице со статьями?). Без главного документа комментарий не имеет вообще никакой ценности.
Использование прокси модели несомненно гораздо лучше прямого переиспользования одной модели, но всё равно несёт свои недостатки:
Замедление обращения к тикетам, из-за раздутия таблицы строками с комментариями
В случае с некоторыми бд - излишнее резервирование места под незаполненные поля (а в случае с двумя таблицами в одной - по-любому куча полей используется строго только в одной модели из двух)
А что делать, если вы захотели для комментария изменить поле, но это поле используется и в тикете, и там эта правка всё сломает?
То, о чём Вы говорили изначально, идеально выносится в абстрактные модели джанги - код лежит в одном месте и управляется централизованно, но в базе данных для каждой модели создаётся отдельная таблица, с нужными только данной модели реквизитами.
А как методами mysql выполнить поиск по нескольким несвязанным таблицам и после выдать на фронт, отсортированныйпо времени ответа лист? я не знаю.
Не понятен кейс, которой вы пытаетесь решить. Можно подробнее?
полнотекстовый поиск по телу тикета или комментария и выдача совпадений в лист отфильтрованный по релевантности (MATCH/AGAINST) , или просто по дате создания обьекта. бизнес кейс: расширенный поиск в тикетах и комментариях.
Расширенный поиск сам по себе не бизнес кейс, а лишь один из инструментов. Кейс же в данном случае, например, поиск обращений с требуемой тематикой.
Я ничего не знаю о Ваших процессах, но мой опыт говорит, что нет ничего страшного сделать два запроса в две таблицы и в окне с результатами явно написать "это тикеты, это комментарии". А последнее, скорее всего, даже улучшит пользовательский опыт.
Да, точно, связи не правильно проставлены. Спасибо за ссылку, там действительно исчерпывающе описано.
Не заметил, что ссылка на копию с переводом яндекса (больше не работает)
Воть оригинал на английском )
А что у вас по SLA? Вы же никак это не контролируете в своей системе.
Да, пока что в данной системе это никак не контролируется. Это всё таки Pet-проект, которым я занимаюсь один, в свободное время. У меня много всяческих идей по поводу развития сервиса, но не всегда есть время и знания, что бы их воплотить в жизнь. В будущем это конечно же планируется добавить SLA, для большей осведомлённости пользователей и повышения качества сервиса.
Yet one great helpdesk on python...
Интересно, но оценивали ли вы стоимость подобной разработки? А ведь это самое интересное.
Сколько чистых ТЗТ в часах потрачено за всё это время? Сможем вместе прикинуть стоимость с учетом среднерыночной ставки разработчика в РФ.
Pet-проект для обучения или как я в одиночку писал Helpdesk