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


Вроде все можно слить в одну базу и каждой записи присвоить ID компании и когда нужно будет получать данные, то в каждом запросе нужно будет указывать ID компании, что не очень удобно.

Так же так как все данные будут в одной базе. То таблицы сильно вырастут в размерах. И если раньше у одной компании максимум 20 000 тыс товаров, то теперь там будет миллионы товаров разных компаний. Что скажется на производительности выборки. Но это вроде решается через партиции, если из сделать по ID компании. В теории разницы не должно быть. На практике не знаю.


Вопрос в том, как правильнее сделать. Хранить данные каждой компании в разных базах или все хранить в одной базе?
Кто как поступил в своих решениях ? Реально ли партиции решат вопрос производительности с миллионами записей ?

Именно поэтому DBA давно выдумали и вовсю использую автоматизированные средства
администрирования.


Тут дело больше не в администрировании (потому как его можно решить), а в том, как лучше и правильнее все организовать?
Со временем будет 1000 баз, а потом 5000 и так далее...

Если у одной компании "максимум 20 000 тыс товаров", то чтобы достигнуть "там будет миллионы товаров" нужно минимум 100 компаний 20к*100=2млн (2 млн - это уже миллионЫ)

2 млн это мелочь для любого сервера

Я не путаю разные базы и разные таблицы. Для этого и нужно дом поле для индетификации.
И все быстро работает когда запросов мало и когда они простые, А когда они большие, то могут возникнуть притормаживания.

И эта статья про то сколько записей можно записать в таблицу тут не причем.

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

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

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

При малом количестве данных в таблицах используя простые индексы можно писать любые запросы и врятли они будут тормозить. С большими таблицами там для одних запросов надо использовать один индекс. Для других другой. И когда запросов тысячи, то пока это отладишь уйдет год. Это не один день. Было бы хоть 100 запросов, то это ладно. А так это проблема. Вроде это помогают решить партиции без более жесткой оптимизации запросов.

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

Приставки это не особо вариант. Делал раньше. Менее удобно писать запросы. Когда будет много таблиц в базе, то это тоже будет очень не удобно. И при 1000 клиентах, смотреть на тысячи таблиц будет совсем не удобно.

Примерно понял. Что лучше отдельные базы.

Есть конкретный опыт ?