LINUX.ORG.RU

CRM и СУБД - сколько таблиц и каких завести?


0

1

Допустим, есть СУБД, в которой решено хранить данные от CRM.

Пусть она будет для начала однопользовательская.

Я себе примерно представляю её работу так: продавец делает в день 50-30 звонков, плюс/минус. В базе должны храниться такие данные:

- информация о существующих компаниях - названия, адреса, контакты, контактные лица, плюс штук пять разных отметок - кто работает с компанией, на какой стадии привлечение покупателя/состоявшееся сотрудничество, насколько крупная компания/какой номенклатурой интересуется. При этом ненужные компании и их данные нужно «хранить вечно», чтобы не ходить по одним и тем же граблям по несколько раз. Это я поместил в одну таблицу.

- Т.н. «клиентские карточки», адов геморрой. Когда у каждой компании есть либо несколько юрлиц, либо одно, но живущее пару месяцев максимум. Таблица с полями «ИНН», «ОГРН» и прочее, привязана к уникальному номеру компании в первой таблице. Есть поле «актуально» с булевскими значениями, чтобы отфильтровывать устаревшие юрлица.

А вот что мне не очень понятно:

- С каждым клиентом есть та или иная история общения, которую хорошо бы хранить - во-первых, из неё можно готовить отчёты, во-вторых, опять же, если с кем-то поссорился или ещё чего - можно посмотреть историю.

- Каждому клиенту менеджер каждый день что-то должен. Подготовить счёт, наругаться за дебиторку, выслать образцы, и т.д. и т.п.; это тоже хорошо бы хранить в базе данных, это должно помогать планированию, помогать составлять отчёты, ну и вообще.

Я пока склоняюсь к тому, чтобы для истории контактов и заданий создать по отдельной таблице (в смысле, одна таблица будет для всех клиентов), но они будут очень быстро пухнуть, по идее.

Может быть, имеет смысл создавать таблицы «История общения» и «Задачи» для каждого из клиентов? Удобно ли тогда будет по ним делать отчёт/какую-нибудь обработку-напоминалку?

В общем, у кого какие соображения?

★★★★★

Я пока склоняюсь к тому, чтобы для истории контактов и заданий создать по отдельной таблице (в смысле, одна таблица будет для всех клиентов), но они будут очень быстро пухнуть, по идее.

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

mashina ★★★★★
()
Ответ на: комментарий от mashina

Хорошая вещь... Боюсь, что сейчас я таким не располагаю. Видимо, буду пока делать недельные таблицы и дропать те, что старее трёх месяцев.

Спасибо.

Hoodoo ★★★★★
() автор топика

Тебе знакомы такие имена, как Дейт, Конолли, Ульман? Нет?

Так вот, эти люди пишут дело. Ты пишешь детский лепет.

anonymous
()
Ответ на: комментарий от Hoodoo

Каким именно «таким» не располагаешь, не секрет? Postgres искаробки не располагаешь? Или почему-либо не нравится?

fat-II
()
Ответ на: комментарий от fat-II

Тока тссс, а то товарищ выше из треда вообще на дерьмо изойдёт - я располагаю только M$ Access. И делаю фигнюшку для личного пользования.

Может потом на кутях переделаю, но это сильно потом.

Hoodoo ★★★★★
() автор топика
Ответ на: комментарий от Hoodoo

Тяжко ж тебе придётся... ;) А в доках копался? Я лет пять за Access не брался — мож, и там уже чего допилили подобного...

Касательно таблиц — на первый взгляд, лучше бы в одну, хотя надо смотреть конкретно — связанная информация сильно различается?

Сильно пухнуть, имхо, не должны бы — информацию ты руками вбиваешь, так? Гигабайта быстро не вобьёшь... Ну, гигабайт, может, и Access не потянет, но и на полста мегов понадобится немало времени

fat-II
()
Ответ на: комментарий от fat-II

У меня старый Access. )

В таблицы лучше в разные - там разные столбцы получаются.

Я уже в принципе с таблицами определился, рисую формы и подписываю функции (или как они в VBA называются) для кнопочек.

Нужна эта штука для того, чтобы не пользоваться экселевской простынёй 400*20, в которой вся история контактов пишется в одну ячейку.

А потом можно быудет действительно переписать в виде отдельного приложения.

Hoodoo ★★★★★
() автор топика
Ответ на: комментарий от Hoodoo

Поставили себе нормальную задачу, но выбрали очень странный инструмент... Ставьте sugarcrm и адаптируйте. Там всё есть и вначале достаточно только понатыкать мышкой.

Aman
()
Ответ на: комментарий от Aman

SugarCRM - платная. Я не готов ни платить сам, ни приводить обоснование расходов для руководства, но работать с клиентской базой в экселе не хочу.

Тем не менее, поделка готова, и я ей даже уже пользуюсь пару дней. Заодно смотрю, какие по ходу использования появляются требования к интерфейсу (сегодня добавил календари на некоторые формы) и какие столбцы и связи между таблицами нужны.

Hoodoo ★★★★★
() автор топика
Ответ на: комментарий от Hoodoo

>SugarCRM - платная.

Ээээээ... Вы бы хоть поинтересовались. GNU GPL v.3. На оф. сайте вылажена куча инсталляторов, разворачивающих весь комплекс open source версии (Apache+php+mysql+SugarCRM). Хоть методом «далее->далее->далее», даже на win-платформе. Есть коммерческие варианты, на чём собственно и живут, но там уже разные навороты. Open Source версия вполне вариант.

Тем не менее, поделка готова

Терпеть не могу Access. Он только усложняет жизнь. Бывало встречал проекты на нём, причём очень большие, упиравшиеся во все его грабли, которые приходилось переводить на нормальную СУБД (ужас, при том что Access в продакшене, совместимость и т.д.). Никогда не понимал, зачем нужно было брать вначале Access, чтоб потом делать кучу работы. Нет, я знаю секретарш, в свободное время на работе изучавших Access и что-то оптимизирующих на нём для своей работы. Это похвально. Это его ниша. Но когда у человека хватает мозга взять нормальную СУБД и делать клиент, тут уже извините.

В CRM нужно думать о workflow, а не о backend с таблицами, связями и прочим. Последнее конечно тоже надо, но не в вашем случае. Если вы решили поучиться делать БД, это одно (да и то Access плохой выбор). Если вам нужно действительно рабочее решение - зачем придумывать ненужный велосипед? К тому же, если решение запуститься в работу - рано или поздно Access нужно будет всё-равно выкинуть.

Aman
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.