Это запрашивает выборку ненужная информация? Я должен изменить запрос?
У меня есть этот веб-сайт объявлений, и у меня есть приблизительно 7 таблиц в MySql, где все данные хранятся. У меня есть одна основная таблица, названная "объявлениями".
В таблице объявлений существует столбец, названный classified_id. Это не PK или ключ вообще. Это - просто число, которое привыкло для меня к записям Объединяющей таблицы вместе.
Исключая:
classifieds table: fordon table:
id => 33 id => 12
classified_id => 10 classified_id => 10
ad_id => 'bmw_m3_92923'
Это выше соединено classified_id столбцом.
Теперь к Q, я использую этот метод для выборки всех записей, ГДЕ столбец ad_id соответствует любому из значений в массиве, названном в этом $ad_arr случая:
SELECT mt.*, fordon.*, boende.*, elektronik.*, business.*, hem_inredning.*, hobby.*
FROM classified mt
LEFT JOIN fordon ON fordon.classified_id = mt.classified_id
LEFT JOIN boende ON boende.classified_id = mt.classified_id
LEFT JOIN elektronik ON elektronik.classified_id = mt.classified_id
LEFT JOIN business ON business.classified_id = mt.classified_id
LEFT JOIN hem_inredning ON hem_inredning.classified_id = mt.classified_id
LEFT JOIN hobby ON hobby.classified_id = mt.classified_id
WHERE mt.ad_id IN ('$ad_arr')";
Это хорошо, или это на самом деле выбрало бы ненужную информацию?
Проверьте этот Q, который я отправил несколько дней назад. В комментариях HLGEM комментирует, что это неправильно и т.д. и т.д. Что Вы думаете?
Другой вопрос о новобранце; Как реализовать количество () здесь?
Спасибо
4 ответа
Вы наверняка возвращаете ненужные результаты, отвечая на ваш вопрос.
Это плохая привычка.
Категорически не согласен с marr75 . Во-первых, потому что, если вы выполняете эту плохую технику в большинстве своих запросов, вы добавляете ненужную нагрузку практически к каждому запросу.Запросы к базе данных должны быть написаны как можно более оптимизированными, так как это чрезвычайно болезненно, чтобы позже переписывать и переписывать каждый запрос в вашей базе данных, потому что вы использовали известную плохую технику. Рефакторинг в базах данных сложен, и при разработке необходимо учитывать производительность, это не преждевременная оптимизация для использования технических приемов, которые, как известно, улучшают производительность с самого начала, это хороший дизайн.
Затем у вас есть проблема с обслуживанием. Если вы зависите от того, что эти столбцы расположены в определенном порядке и кто-то меняет структуру базы данных, вам не повезло. Алос, если кто-то добавляет столбец, который вы не хотите показывать пользователю (что является обычным явлением), вам не повезло. Это очень плохая техника, и select * почти никогда не следует использовать в производственной системе. Если кто-то добавит столбец, он будет возвращен в запросе, но вам нужно знать, что было добавлено и почему, чтобы интерфейс все равно делал то, что ему нужно, поэтому вы не сэкономите на обслуживании, используя этот плохой метод.
Специальные запросы
Это запросы, которые вы пишете для выполнения один раз или в редких случаях.
Какой размер результирующего набора данных вы должны вернуть, чтобы выполнение SELECT * заняло больше времени, чем ввод имен столбцов?
Какова вероятность того, что вы забудете столбец, добавив его , и придется запускать его снова?
Ваше время дороже, чем процессорное время. Если вы запускаете его один раз, позвольте базе данных делать всю работу. SELECT * подходит для специальных запросов, если это сэкономит ваше время.
Есть исключения, такие как поля Blob в больших наборах данных, но суть вы поняли.
Рабочие запросы
Это запросы, которые хранятся в вашем приложении или базе данных. Эти запросы выполняются часто.
Сколько раз вам нужно запускать запрос, чтобы компенсировать время, необходимое для присвоения имен столбцам? Он быстро накапливается.
Назовите свои столбцы в производственных запросах, чтобы ваше приложение могло лучше масштабироваться и работать с максимальной эффективностью. Есть и другие незначительные преимущества, но они не так интересны.
Сводка
- Добавить Hoc-запросы:
SELECT *в целом нормально. - Производственные запросы:
SELECT *всегда неверно. - Быть немного ленивым - это нормально, но будьте осторожны.
Это вопрос мнения. Есть ли у вас проблемы с производительностью или масштабированием? Если нет, то конкретизация того, какие столбцы возвращать, вероятно, является вопросом преждевременной оптимизации. Дублирование столбцов целочисленного соединения не приведет к тому, что в ближайшее время банк пропускной способности будет разрушен.