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

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

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

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

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


mysql sql data-modeling database-design
person waywardspooky    schedule 24.10.2009    source источник
comment
Создайте структуру для работы с несколькими пользователями. Если вы правильно проиндексируете свои таблицы, вы увидите отличную производительность. Любой администратор баз данных, который действительно спроектирует что-то так, как этого хочет ваш босс, должен быть немедленно уволен. Это ужасная практика.   -  person    schedule 24.10.2009

Ответы (6)


arrow_upward
4
arrow_downward

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

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

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

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

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

person cletus    schedule 24.10.2009
comment
Честно говоря, это звучит плохо с точки зрения разработки и развертывания. - person ; 24.10.2009

arrow_upward
1
arrow_downward

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

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

person mjv    schedule 24.10.2009

arrow_upward
0
arrow_downward

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

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

person pgb    schedule 24.10.2009
comment
К сожалению, у нас ограниченное количество баз данных, которые мы можем запустить. Я думаю, что у нас может быть всего около 10 баз данных. - person waywardspooky; 24.10.2009
comment
Я не поддерживаю новую БД для каждого клиента, но если у вас может быть только 10 БД, вам нужно сказать своему боссу, чтобы он прекратил использовать какую-то однодневную хостинговую компанию за 1 доллар в месяц и получил реальные бизнес-услуги. - person phoebus; 24.10.2009

arrow_upward
0
arrow_downward

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

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

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

person MarkR    schedule 24.10.2009

arrow_upward
0
arrow_downward

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

person waywardspooky    schedule 26.10.2009

arrow_upward
0
arrow_downward

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

person Bernard Igiri    schedule 02.02.2011