Скорость обработки данных в PHP против MySQL

Question

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

У меня есть зарегистрированные пользователи (в таблице пользователей), и у меня есть страны (в таблице стран) примерно следующим образом:

ТАБЛИЦА ПОЛЬЗОВАТЕЛЕЙ: user_id (PK, INT) | country_id (FK, TINYINT) | другие пользовательские поля ...

ТАБЛИЦА СТРАН: country_id (PK, TINYINT) | название страны (VARCHAR) | другие поля, относящиеся к стране ...

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

Мне интересно, каковы могут быть плюсы и минусы выведения стран из базы данных и помещения их в класс в виде массива, из которого я могу легко получить их с помощью открытых вызовов методов с использованием country_id? Будет ли преимущество в скорости / недостаток скорости?

Большое спасибо.

РЕДАКТИРОВАТЬ: Спасибо за все мнения, очень полезно. Я выберу первый ответ в качестве принятого решения, хотя все вклады оценены.

Answer 1

Есть ли у вас серьезные проблемы с производительностью сейчас? Недавно я прошел улучшение производительности на сайте php / mysql, который я разработал для своей компании. Некоторые области были слишком медленными, и оказалось, что большая ошибка была в самих запросах. Я использовал таймеры, чтобы выяснить, какие запросы были медленными, и реорганизовал их (добавили индексы и т. Д.). В некоторых случаях было быстрее сделать два отдельных запроса и объединить их в php (у меня было несколько довольно сложных объединений).

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

Answer 2

Общее правило в мире баз данных - сначала НОРМАЛИЗИРУЕТСЯ (приводит к большему количеству таблиц), а потом анализирует проблемы с производительностью.

Вам нужно ДЕНОРМАЛИЗОВАНО только для простоты кода, а не для производительности. Используйте индексы и хранимые процедуры. СУБД предназначены для оптимизации соединений.

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

Answer 3

Не думаю, что вы что-то выиграете от удаления объединения, поскольку вам придется перебирать все строки результатов и вручную искать название страны, что, я сомневаюсь, будет быстрее, чем MySQL.

Я также не стал бы рассматривать такой подход по следующей причине: если вы хотите изменить название страны (например, у вас есть опечатка), вы можете сделать это, просто обновив строку в базе данных. Но если названия стран есть в вашем PHP-коде, вам придется заново развернуть код, чтобы внести изменения. Я не знаю PHP, но это может быть не так просто, как изменение БД в производственной системе.

Так что по причинам ремонтопригодности, IMHO, пусть БД сделает работу.

Answer 4

То, что вы предлагаете, должно быть быстрее. Конечно, объединение, вероятно, не будет стоить дорого, но поиск в словаре должен быть почти бесплатным, поскольку вычислительная мощность идет.

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

Answer 5

На вашем сервере MySQL будет меньше стресса из-за того, что у вас будет меньше операторов JOIN, но не так значительно (в мире не так много стран).Тем не менее, вы воспользуетесь этим моментом тем фактом, что вам придется самостоятельно внедрять JOIN в PHP.И поскольку вы пишете это самостоятельно, вы, вероятно, напишите его менее эффективно, чем оператор SQL, а это значит, что это займет больше времени.Я бы рекомендовал хранить его на сервере SQL, поскольку преимущества его перемещения очень малы (и если экземпляр PHP и экземпляр MySQL находятся в одном окне, реальных преимуществ нет).