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