Многопользовательская архитектура

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

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

Каковы недостатки этого?

Один стол в основном будет столом лидеров,
разделены несколькими компаниями.
При текущем размере это около 15 000 000 строк.
Каковы последствия того, что эта таблица становится слишком большой, и как бы я справился с этим?

Salesforce имеет базу данных Oracle с одной таблицей.
Который должен быть массивным !!
Мне просто интересно, как они справляются с постоянно обновляемым набором данных, с точки зрения кэширования и блокировки и т. Д.

0

Решение

Используете ли вы какие-то конкретные рамки для вашего приложения? Laravel имеет базу данных migration (http://laravel.com/docs/4.2/migrations) функциональность, которая позволяет обновлять схему базы данных и автоматически откатывать ее из командной строки. Вы также можете использовать такие инструменты, как Chef или же Puppet чтобы помочь вам автоматизировать ваши базы данных с помощью сценариев, которые могут контролироваться версиями.

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

0

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]