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

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

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

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

Приветствия

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

Недостатки:

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

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

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

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

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

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