MYSQL, используя уникальные имена таблиц VS, используя идентификаторы

Question

В настоящее время у меня есть 26 таблиц в базе данных MYSQL. Мой начальник хочет, чтобы я заново создавал эти 26 таблиц всякий раз, когда у нас появился новый клиент, и добавлял какое-то сокращение клиента в эти новые таблицы. Так, например, есть company1 ~ system ~ users и company2 ~ system ~ users и так далее и тому подобное.

Я бы предпочел просто добавить в базу данных таблицу, которая отслеживает наших клиентов, с автоматически возрастающим 11-значным первичным ключом INT и ссылаться на него в других 26 таблицах, поэтому мы не загромождаем базу данных 4000 таблиц, если есть 200 клиентов.

Я думаю, что он боится, что если мы пойдем по методу, который я предпочел бы сделать, MYSQL потребует заметно больше времени для выполнения запросов, потому что клиенты с где-то между 2000 и 5000 записями будут совместно использовать таблицы. Так, например, поиск пользователей, принадлежащих company1, из таблицы, называемой system ~ users с 1 500 000 записей, будет медленнее, чем поиск пользователей из таблицы, называемой company1 ~ system ~ users с 2 000 записей. Я думаю, что на самом деле поиск MYSQL будет медленнее, если у каждого нашего клиента будет 26 наборов таблиц (это 26 для каждого клиента).

Какой метод на самом деле медленнее?

Answer 1

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

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

Если это не тот случай, он может нормально работать, быть неловким или хорошим в зависимости от вашей установки, используемой платформы и т. Д.

Добавление названия компании - это взлом, но его можно заставить работать, я думаю.

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

Answer 2

200 клиентов * 5000 записей [в любой заданной таблице] малы по стандартам базы данных. При условии, что вы добавите идентификатор клиента в качестве первого ключа большинства индексов, предложенная вами схема не должна приводить к заметному снижению производительности.

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

Answer 3

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

Answer 4

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

Answer 5

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

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

Сделай самое простое, что могло бы сработать. Просто держите их в одном наборе столов.

Answer 6

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

Что касается добавления идентификатора к именам таблиц, почему бы вам не рассмотреть возможность создания отдельного экземпляра базы данных? Я думаю, что для изменения имен таблиц может потребоваться дополнительное кодирование (чтобы динамически генерировать имена таблиц в любом запросе), когда использование разных экземпляров кажется простым.