Запросы Mysql VIEWS против PHP

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

Основное различие заключается в том, что представления обновляются после каждой вставки, так что данные «готовы» всякий раз, когда вы запрашиваете представление, тогда как использование вашего пользовательского запроса будет каждый раз вычислять MySQL каждый раз (конечно, есть кеширование).

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

Мой полный ответ будет зависеть от нескольких вещей (с точки зрения вашего приложения):

• Планируете ли вы разрешить пользователям создавать и распространять такие списки?
• могут ли пользователи создавать списки любого типа или просто подключать значения к существующим шаблонам запросов?

Предполагая, что у вас есть пара предопределенных списков для отображения:

Использование представлений предлагает несколько преимуществ:

• ваш код будет чище
• запрос на создание представлений не должен каждый раз анализироваться mysql.

Я не уверен в этом: я не думаю, что mysql кэширует представления, как предлагает Томаш, – я не думаю, что мнения содержат «уже подготовленные данные».

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

ура

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

Не является ли одним из недостатков взглядов, что они могут дать вам ложный комфорт при выполнении простого запроса? Например, SELECT username FROM myview WHERE id = '1' Это выглядит просто, но что, если «myview» является действительно сложным SELECT … Возможно, даже построено на других представлениях? В итоге у вас есть простой запрос, который на заднем плане требует гораздо больше работы, чем если бы вы написали свой запрос с нуля.

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

Если эти таблицы, которые вы пытаетесь просмотреть, не подвержены частым изменениям, определенно вы получаете производительность, поскольку вы делаете простой выбор из уже подготовленных данных. Но имейте в виду, что эта точка зрения не является чем-то, что делается «раз и навсегда» – каждое изменение содержимого одной из таблиц заставит механизм базы данных «просматривать обновление», поэтому другой запрос (запрос, который вы создаете из) должны быть вызваны с учетом изменений, которые были сделаны. Подводить итоги:

Нечастые изменения? Представление. Частые / постоянные изменения (добавление сообщества, комментирование, оценка ваших ресторанов) – лучше пойдите с SQL-запросами.

Недостатки:

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

• Теперь, когда код находится внутри базы данных, также добавляются проблемы безопасности и доступа (к представлениям и хранимым процедурам).

• Перенос приложения из одного механизма базы данных в другой будет намного сложнее (поскольку в дополнение к простым запросам, хранимые процедуры / представления и т. Д., Возможно, тоже отличаются). Если база данных относится только к данным, тогда уровень абстракции может позволить изменить механизм базы данных (по крайней мере, в некоторой степени).

Преимущества:

• Небольшая прибыль (поскольку данные не выводятся из базы данных для обработки, они обрабатываются прямо внутри базы данных).

• Код будет казаться более чистым (поскольку загрязнение скрыто внутри представлений базы данных, хранимых процедур и т. Д.).