Здравствуйте уважаемые гуру!
Суть вопроса, есть CRM для одной фирмы, стабильно работает на PHP-шном фрэймворке (MVC), обычные запросы SQL, без memcached, скрипты JQUERY.
Вообщем всё работает стабильно, появилась задача, сделать это для многих компаний, для каждой создавать свой отдельный сайт и базу не вариант, надо из одного.
Смотря на имеющуюся базу понимаю что одной таблицы , мало, для каждой новой компании создавать свои таблицы и по номеру главного пользователя выбирать её? Но это приведёт к огромному числу таблиц.
Куда смотреть в плане PHP фрэймворка и JS ,
Вообщем с удовольствием пообщаюсь на эту тему и почитаю предложенные материалы .
Если она изначально не multi-tenancy, то никак.
Если бы была спроектирована под mutli-tenancy - просто в каждой таблице дополнительное поле и фильтровать ВСЕГДА по нему, чтобы не видеть чужих данных. Но чтобы сейчас, на готовой уже системе, так сделать - это глубоко лопатить код с риском, что увидят чужие данные, если вы ошибетесь.
я ввёл уже дополнительное поле, в принципе записи выводятся правильно, чужие не выскакивают, но из за чего поднял вопрос, допустим таблица логов, там сейчас порядка 20 000 записей, и это одна фирма, а когда будет 100 фирм ? соответственно какая нагрузка на бд
Aristokratu:
Ну во-первых, для СУБД нагрузка даже в миллионы строк - это не нагрузка, они для этого приспособлены.
Во-вторых, все же писать логи в БД это перебор. Как вы думаете, а почему логи практически всегда пишутся в файлы отдельные (обычно текстовые, реже - бинарные)? ))))
В-третьих, если сильно хочется хранить логи именно в БД, то я бы выбрал под логи более специализированную БД, заточенную под подобную нагрузку.
Aristokratu: Если запросы к базе правильные - никакой нагрузки не будет.
К примеру:
При пагинации получать последний id, делать выборку товаров где id > последнего. Никаких оффсетов (на 100й странице при 10 записях на странице mysql загрузит все 1010 записей).
Никаких groupBy во вложенных запросах и джойнах.
Правильное использование индексов.
"Жадная" загрузка, свести запросы к минимуму (3-4 запроса на странице при большом количестве данных - норма)
И это только маленькая часть того, что надо предусмотреть.
Так что, увы, без больших познаний в бэкэнд-девелопменте (и конкретно без познаний того фреймворка, на котором написана система) далеко не уйдете. При парочке других клиентов вся система с базой вовсе рухнет.
Советую сделать все с нуля. Изучите Laravel, уверен, после изучения вы сможете написать за месяц такую же систему. Может даже лучше.
Andrzej Wielski:
> вы сможете написать за месяц такую же систему
Откуда такие оценки. Вы до сих пор только сайтами-визитками занимались и ничего серьезного не делали, что ли?
По странному совпадению я участвую сейчас в подобной разработке. За 2 недели удалось написать около 5%. Альфа-версия будет только после месяцев 4-5....
four4: возможно не правильно написал, логи в том случае это изменения записи какой либо, допустим есть клиент вася пупкин и ему поменяли номер телефона, это заноситься в лог клиента
four4: а что именно пишите, что сейчас 5% ? У меня CRM-ка получилась за 1.5 месяца рабочий функционал, плюс ещё 1 на внесение правок, но уже на рабочий вариант
Aristokratu:
То есть список хозяев квартир и самих квартир с их адресами и телефонами, выложенный в интернет.
Ну CRM это можно назвать с большой натяжкой, не в обиду вам будет сказано.
Скажем, на базе 1С Предприятие такой функционал можно написать за дня 3 (включая историю изменений отдельных полей данных).
В моем представлении CRM это хотя бы функционал SugarCRM, не говоря уже о Salesforce, у которых вообще бабла миллиарды.
four4: Нет, не в обиду, что было необходимо клиенту он всё получил. И это только основные функции, там есть и вспомогательные , которых быть может там не много но их хватает для удобной работы
Aristokratu:
Это типовая автоматизация предприятия, таких миллион.
Да, конечно, она CRM-подобная. Согласен. Но это не CRM-система.
Хотя, с точки зрения маркетинга, называть её громким словом CRM, разумеется, лучше. )))
four4: хорошо, что вы вкладываете в понятие CRM ? Хотя больше меня интересует, что вы используете при разработке ? и та CRM в разработке которой вы принимаете участие многопользовательская , то есть для большого количества фирм или одной ?
А почему одной таблицы мало?.. Измените структуру - в одной таблице храните аккаунты, во второй - записи, которые эти аккаунты будут вносить (по аналоги ис уже имеющейся таблицей). В таблицы с данными просто будете заносить id пользователя, и все.
Записей, конечно, будет много, поэтому придется уделить вопрос оптимизации (как минимум определить самые частые выборки).
Если не хочется плодить таблицы, можно сделать одну таблицу, в которую вы будете добавлять компании, которые подключаются к вашей CRM и идентификатор из этой таблицы использовать как ключ во всех таблицах, где требуется разделение данных по компаниям.
