Я создаю CRM-систему типа salesforce.com - какова правильная архитектура базы данных?

Question

Я разработал CRM для своей компании.Далее я хотел бы взять эту систему и сделать ее доступной для использования другими в размещенном формате.Очень похоже на salesforce.com.Вопрос в том, какой тип структуры базы данных я бы использовал.Я вижу два варианта:

Вариант 1. Каждый раз, когда компания регистрируется, я клонирую основную базу данных для них.

Недостатком этого является то, что я могу закончитьс тысячами баз данных.Это много баз данных для резервного копирования каждую ночь.Мой CRM использует задания cron для обслуживания, эти задания должны выполняться во всех базах данных.

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

Вариант 2. Используйте только одну базу данных.

В начале КАЖДОЙ таблицы добавьте "CompanyID".В КАЖДОМ выражении SQL добавьте «and companyid = {companyid}».

Преимущество этого метода заключается в простоте только одной базы данных.Всего одна база данных для резервного копирования каждую ночь.Только одна база данных для обновления, когда это необходимо.

Недостатком является то, что если я получу подписку от 1000 компаний, и каждая из них хочет сохранить данные по 100 000 заявок, то есть 100 000 000 строк в таблице заявок, что меня беспокоит.

Кто-нибудь знает, как это делают размещенные в Интернете CRM, такие как salesforce.com?

Спасибо

Answer 1

Не хотите ли вы клонировать стиль структуры таблицы для каждой новой базы данных, если все листы, заархивированные в индексированном клиентском клоне главной базы, проверены на хэш для доступа к конкретному листу, проходящему через хост-машину во внешней системе главной системы. Затем направление запросов в качестве основной роли. Внутренний доступ предназначен для чтения / записи подчиненных систем в группах. Очевидно, настройки рейда для копирования в режиме реального времени и по расписанию. Баланс запросов на загрузку по скорости системных ресурсов. Таким образом вы отделили недостатки безопасности от пользовательского интерфейса и подключения к схеме хранения. похоже, что упрощенные структуры и сокращение запросов политики сокращают количество запросов rss при обработке запросов. или просто человек посередине приближается изнутри.

Answer 2

1) Разделение ваших данных на более мелкие группы безопасным, бездумным способом (например, одна база данных на группу) почти всегда лучше, если вы хотите масштабировать. В этом случае, если по какой-то причине вы не хотите делать запросы между компаниями, лучше всего хранить их в отдельных базах данных.

2) Если вы обновляете все базы данных вручную, вы делаете что-то не так, если хотите масштабировать. Вы хотели бы автоматизировать процесс.

3) В конечном счете, salesforce.com использует это в качестве основы своей инфраструктуры БД: http://blog.database.com/blog/2011/08/30/database-com-is-open-for-business/