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

0

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

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

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

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

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

Теги:
multi-tenant

1 ответ

0

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

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню