Может ли быть хорошей идеей создать новую таблицу для каждого клиента веб-приложения?

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

Представьте себе веб-приложение, скажем, бухгалтерское программное обеспечение, которое имеет 20 000 клиентов, и каждый клиент имеет более 1000 записей в таблице. Это 20 миллионов строк, которые, я знаю, могут замедлить сложные запросы.

В таком случае имеет ли смысл создавать новую таблицу в базе данных для каждого клиента? Как базы данных реагируют на наличие 20 тыс. (Или более!) Таблиц?

В общем, нет, нет смысла иметь таблицу (я думаю, вы на самом деле имеете в виду базу данных здесь) для каждого клиента. 20 миллионов строк сравнительно мало для таблицы базы данных. Скорость выполнения запросов не должна быть проблемой, если база данных правильно настроена (проиндексирована) и запросы правильно составлены. Какую бы выгоду вы, по вашему мнению, не получили, разделив их, вы компенсируете дополнительную сложность управления 20 000 отдельных баз данных. Например, что происходит, когда вы хотите изменить структуру таблицы? Теперь вы должны сделать это 20000 раз!

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

Похоже, плохая идея.

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

Кроме того, как общее правило. Я предлагаю не создавать базу данных таким способом, который требует манипулирования или создания структур базы данных (таблиц, полей) во время обычного использования приложения. Это делает оптимизацию для производительности медленным и часто вынуждает вас давать слишком много разрешений пользователям для выполнения рутинных задач, потенциально создающих дыры в безопасности.

Вот статья, которую я всегда призываю людей читать, когда они задают этот вопрос:

http://datacharmer.blogspot.com/2009/03/normalization-and-smoking.html

ИМХО, единственная таблица не должна быть проблемой, поэтому не создавайте проблему там, где ее нет - пока. Вы можете многое сделать для повышения производительности. Вы можете разделить одну таблицу на несколько файлов на основе clientID или поля даты, чтобы помочь с IO. Ваша БД не должна отслеживать, оптимизировать и кэшировать 20 000 различных SQL-операторов для каждого запроса, который понадобится вашему сайту. Вы можете индексировать по клиенту. Клиенты 20K могут заплатить за большое количество оборудования.

Для этого типа таблицы можно использовать NoSQL типа db.

С 20K-клиентами база данных может быть не самым слабым звеном, так зачем вводить такую ​​сложность?

Это действительно плохой подход.

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

Сортируйте данные по user_id и, если это невозможно, получите огромное количество RAM или SSD дисков.