|
Архитектура базы данных - "Поддержка пользователей"?
|
|||
---|---|---|---|
#18+
Здравствуйте, нужно сделать простенький support. Типо пользователь создаёт вопрос и потом поддержка отвечает на него. Получается своеобразная переписка. Между поддержкой и пользователем. Если вопрос решён, то установить спец статус и всё. Больше ничего не нужно.. Ноо, мне почему-то кажется, что я что-то упускаю или обдумал неверно.. Есть user, у него список support объектов. ( One to many) Есть support, у него список support_conversation объектов. ( One to many) Подскажете что-то? Спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2018, 11:55 |
|
Архитектура базы данных - "Поддержка пользователей"?
|
|||
---|---|---|---|
#18+
Если все что нужно, это переписка между юзером и техподдержкой, то в SupportItem таблице должны будут оказаться основные данные о проблеме (когда создан тикет, кем, оглавление и время), и таблица переписки, где SupportPersonId будет nullable и содержит id человека из поддержки написавшего ответ. SupportPersonId = Null если сообщение принадлежит пользователю SupportItem -Id -Subject -Time -UserId -Status SupportConversation -SupportItemId -Message -MessageTime -SupportPersonId ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2018, 01:49 |
|
Архитектура базы данных - "Поддержка пользователей"?
|
|||
---|---|---|---|
#18+
в случае если несколько человек из суппорта могут отвечать на одно и то-же сообщения пользователя, либо если требуется разделять вопросы и ответы на них - то ответы можно выносить в отдельную таблицу либо вообще превратить в дерево сообщений ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2018, 02:14 |
|
Архитектура базы данных - "Поддержка пользователей"?
|
|||
---|---|---|---|
#18+
StalkerSЕсли все что нужно, это переписка между юзером и техподдержкой, то в SupportItem таблице должны будут оказаться основные данные о проблеме (когда создан тикет, кем, оглавление и время), и таблица переписки, где SupportPersonId будет nullable и содержит id человека из поддержки написавшего ответ. SupportPersonId = Null если сообщение принадлежит пользователю SupportItem -Id -Subject -Time -UserId -Status SupportConversation -SupportItemId -Message -MessageTime -SupportPersonId Большое спасибо за ответ. Исходя из вашего комментария и из того что написал я, то всё приблизительно я сделал правильно. Спасибо, что подтвердили. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2018, 13:27 |
|
Архитектура базы данных - "Поддержка пользователей"?
|
|||
---|---|---|---|
#18+
StalkerSв случае если несколько человек из суппорта могут отвечать на одно и то-же сообщения пользователя, либо если требуется разделять вопросы и ответы на них - то ответы можно выносить в отдельную таблицу либо вообще превратить в дерево сообщений - думаю, что пока нечего усложнять, пока просто так как я и написал, будет нужда добавлю и поля и таблицы дополнительные. Спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2018, 13:28 |
|
Архитектура базы данных - "Поддержка пользователей"?
|
|||
---|---|---|---|
#18+
_webdev_, а чем у вас send_time отличается от reply_time? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2018, 14:12 |
|
Архитектура базы данных - "Поддержка пользователей"?
|
|||
---|---|---|---|
#18+
Дедушка_webdev_, а чем у вас send_time отличается от reply_time? - хммм, да, send_time можно убрать, так как оно будет соответствовать первой записи вопроса в таблице "support_conversation" ... |
|||
:
Нравится:
Не нравится:
|
|||
15.04.2018, 19:00 |
|
Архитектура базы данных - "Поддержка пользователей"?
|
|||
---|---|---|---|
#18+
_webdev_Ноо, мне почему-то кажется, что я что-то упускаю или обдумал неверно.. В общем, довольно много. Прежде всего, в переписке с техподдержкой практически всегда требуется прикладывать файлы. Соответствующую фичу лучше всего внести в support_conversation. Далее, у каждого сообщения должен быть автор. Лично я бы вообще выделил общую сущность person и расширяющие её user и supporter. В support (неудачное название, лучше ticket) нужна обязательная ссылка на первое сообщение, а в самих сообщениях - какая-либо иерархия, последовательность. Сейчас они лежат просто беспорядочной грудой, в которой разве что по reply_time можно попытаться как-то разобраться (и приготовьтесь к большому празднику с авторами из разных часовых поясов). Про сообщения надо решить - хранятся ли они плоским списком либо деревом и, соответственно, добавить в них либо order_no, либо parent_id. Поле subject в сообщениях совершенно лишнее, ему место в support (никто не будет писать отдельные сабжекты у каждой реплики). Про send_time уже сказали. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2018, 11:27 |
|
Архитектура базы данных - "Поддержка пользователей"?
|
|||
---|---|---|---|
#18+
softwarer_webdev_Ноо, мне почему-то кажется, что я что-то упускаю или обдумал неверно.. В общем, довольно много. Прежде всего, в переписке с техподдержкой практически всегда требуется прикладывать файлы. Соответствующую фичу лучше всего внести в support_conversation. Далее, у каждого сообщения должен быть автор. Лично я бы вообще выделил общую сущность person и расширяющие её user и supporter. В support (неудачное название, лучше ticket) нужна обязательная ссылка на первое сообщение, а в самих сообщениях - какая-либо иерархия, последовательность. Сейчас они лежат просто беспорядочной грудой, в которой разве что по reply_time можно попытаться как-то разобраться (и приготовьтесь к большому празднику с авторами из разных часовых поясов). Про сообщения надо решить - хранятся ли они плоским списком либо деревом и, соответственно, добавить в них либо order_no, либо parent_id. Поле subject в сообщениях совершенно лишнее, ему место в support (никто не будет писать отдельные сабжекты у каждой реплики). Про send_time уже сказали. - Пасиб, дельные советы. Пока что не ожидается много запросов и прям настоящего саппорта, просто, чтоб в начале можно было как-то помогать пользователю, если возникнут трудности. И отвечать будет один пользователь.. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2018, 22:27 |
|
Архитектура базы данных - "Поддержка пользователей"?
|
|||
---|---|---|---|
#18+
_webdev_Пока что не ожидается много запросов и прям настоящего саппорта, просто, чтоб в начале можно было как-то помогать пользователю, если возникнут трудности. И отвечать будет один пользователь.. Тогда поставьте любой бесплатный форум и вообще не заморачивайтесь. Просто когда вопрос решён - закрывайте топик или там переносите в архив. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2018, 22:38 |
|
Архитектура базы данных - "Поддержка пользователей"?
|
|||
---|---|---|---|
#18+
softwarerТогда поставьте любой бесплатный форум и вообще не заморачивайтесь. - ээээм, немного не понял - для чего? У меня мой нативнй java бекенд и так д... 100500 раз будет дороже интеграцию какую-то проводить.. softwarerПросто когда вопрос решён - закрывайте топик или там переносите в архив. - у меня нет таких полномочий, опций. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2018, 22:46 |
|
Архитектура базы данных - "Поддержка пользователей"?
|
|||
---|---|---|---|
#18+
_webdev_ээээм, немного не понял - для чего? Для саппорта. Пользователь, которому нужна помощь, создаёт топик на форуме. Саппорт ему там отвечает. Вот и всё. Не нужно никакой дополнительной базы, никакой интеграции и так далее. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2018, 22:49 |
|
Архитектура базы данных - "Поддержка пользователей"?
|
|||
---|---|---|---|
#18+
softwarerДля саппорта. Пользователь, которому нужна помощь, создаёт топик на форуме. Саппорт ему там отвечает. Вот и всё. Не нужно никакой дополнительной базы, никакой интеграции и так далее. - понял Вас. Нууу, с моей точки зрения - это "over engineering". ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2018, 22:53 |
|
Архитектура базы данных - "Поддержка пользователей"?
|
|||
---|---|---|---|
#18+
softwarer_webdev_ээээм, немного не понял - для чего? Для саппорта. Пользователь, которому нужна помощь, создаёт топик на форуме. Саппорт ему там отвечает. Вот и всё. Не нужно никакой дополнительной базы, никакой интеграции и так далее. Очень несекьюрное решение. Я бы, скажем, был бы категорически против, чтобы мою переписку с саппортом (со всеми скриншотами, настройками и т.п.) видела каждая свинья, пользующаяся тем же сервисом (и, соответственно, имеющая возможность зайти на тот же форум) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2018, 23:21 |
|
Архитектура базы данных - "Поддержка пользователей"?
|
|||
---|---|---|---|
#18+
Кот МатроскинОчень несекьюрное решение. А требований по секьюрности и не выставлено. Кот МатроскинЯ бы, скажем, был бы категорически против, чтобы мою переписку с саппортом (со всеми скриншотами, настройками и т.п.) видела каждая свинья, пользующаяся тем же сервисом (и, соответственно, имеющая возможность зайти на тот же форум) В животных Вы, конечно, разбираетесь лучше меня, но что касается сути возражения - оно имеет смысл только в некоторых областях деятельности, в большинстве случаев эти "скриншоты и настройки" глубоко по барабану. И даже в них задача дописать в select * from topics фразу where user = ? вряд ли представляет такую уж нерешаемую задачу. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2018, 23:31 |
|
Архитектура базы данных - "Поддержка пользователей"?
|
|||
---|---|---|---|
#18+
softwarer Кот МатроскинЯ бы, скажем, был бы категорически против, чтобы мою переписку с саппортом (со всеми скриншотами, настройками и т.п.) видела каждая свинья, пользующаяся тем же сервисом (и, соответственно, имеющая возможность зайти на тот же форум) В животных Вы, конечно, разбираетесь лучше меня, Конечно - у нас в Простоквашино без этого никуда. softwarerно что касается сути возражения - оно имеет смысл только в некоторых областях деятельности, в большинстве случаев эти "скриншоты и настройки" глубоко по барабану. И даже в них задача дописать в select * from topics фразу where user = ? вряд ли представляет такую уж нерешаемую задачу. Одна беда - работать не будет :) требуется показывать топики не только их автору, а автору + группе суперпользователей "саппорт". Т.е. нужно разобраться, как хранятся группы пользователей в конкретной поделке, найти все места, где показываются сообщения/топики, везде внести изменения, когда в поделке сообщество обнаружит очередную дыру - каждый раз мержить свои изменения с новой версией... На мой взгляд, этот процесс довольно сложно назвать softwarer вообще не заморачивайтесь ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2018, 09:29 |
|
Архитектура базы данных - "Поддержка пользователей"?
|
|||
---|---|---|---|
#18+
softwarerА требований по секьюрности и не выставлено. - господа, да. Такие аспекты не уточнял, так как есть задача которую хотел решить так как описал. Речь идёт о обычной переписке в личном кабинете каждого зарегистрированного пользователя. Тоесть, если у человека возникнет вопрос к сервису - он в личном кабинете сможет создать тикет и на него ответят. Вот в этом и задумка, для этого нужно несколько дополнительных табличек, о которых я и поинтересовался на форуме. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2018, 09:38 |
|
|
start [/forum/topic.php?fid=32&fpage=8&tid=1540050]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
74ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
others: | 11ms |
total: | 183ms |
0 / 0 |