LINUX.ORG.RU

Вопросик

 ,


0

1

Во многих примерах вижу выборку не всех полей select * а только некоторых select id, name
Насколько это влияет на производительность? Ну данных больше в localhost будет гоняться, ещё что? Нужно ли этими полями заморачиваться или не стоит оно этого?

★★★

Ну данных больше в localhost будет гоняться, ещё что?

Еще данных с диска будет больше читаться. Больше памяти тратится в программе, особенно если есть блоб-поля или большие тексты.

goingUp ★★★★★ ()
Ответ на: комментарий от goingUp

не всегда: если логика построена на самом sql и вместо вещественной таблицы - view, то для фронта вполне оправданно не замарачиваться на тонкости, вернее даже обязательно для унификации логики.

Anoxemian ★★★★★ ()
Ответ на: комментарий от Anoxemian

С чего бы не всегда? Унификация разве не интерфейсом модели достигается? Таким образом модель знает какие поля нужны, подкапотные вопросы ты инкапсулируешь там. У тебя же пример из разряда «нахер заморачиваться и так сойдет». Даже если нужны все — перечисляй явно (проперти модели).

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

Ты не совсем понял. Современные MVC легко упрощаются до VC, где функции MV вполне реалзуются средствами самой СУБД, причем любой реляционной. Т.е. само понятие activerecord в коде frontend'a теряет свой смысл. И тогда тебе действительно достаточно и нужно только select *. Любое нагромождение своего кода\фреймворка вокруг задач самой СУБД неминуемо приведет к повторению алгоритмов реализации DSL'а в виде устаканенного SQL. А это усложнение в 100500 раз, т.к. столько человекочасов на любой дурацкий проект тратить не имеет смысла. Другими словами, любая современная реляционная SQL СУБД может мимикрировать под NoSQL БД.

No offence же)

Anoxemian ★★★★★ ()
Ответ на: комментарий от goingUp

Понятно, что теоретически больше, но главный вопрос *насколько* больше и стоит ли заморачиваться. Блобов нет, сайт не миллион пользователей, но планируется до 10000. Нужны тесты общей разницы в select * и без *. Делать такие тесты не совсем просто. Интересует реальная разница в попугаях )

gobot ★★★ ()
Ответ на: комментарий от Anoxemian

Ты снова про «и так сойдет». Я вижу твои аргументы, но есть и обратные.

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

Ок, велосипед, без моделей, прямыми запросами, стОит заполнять «структуры» выборкой из бд явно перечисляя поля-проперти (как пример, актуальны для ТС пыховые PDO::FETCH_INTO, PDO::FETCH_OBJ). Приложение просто обязано манипулировать готовыми кучками данных без всего лишнего (это те же «MVC упрощаются до VC»). И даже вьюху (бд) стОит выбирать не звездочкой т.к. данные из бд должны передаваться в приложение настолько явно, насколько это возможно.

deep-purple ★★★★★ ()
Ответ на: комментарий от gobot

Возьми да померяй — титла, текстновости, выбирай в одном случае только титлу, в другом звездочкой, сделай 10к запросов в цикле, посчитай сколько заняло памяти.

deep-purple ★★★★★ ()
Ответ на: комментарий от gobot

Померять то я могу, хотел услышать реальные примерны, на личном опыте

А толку? Зависит от общего числа полей и их размера, а также от числа тех полей, которые выводятся явно (когда без *) и их размера.

Также зависит от размеров выборки и объёма ОЗУ.

От скорости диска.

Возможно, от используемой СУБД и модели.

Разных комбинаций может быть чуть меньше, чем бесконечно. Поэтому если у кого-то на другой СУБД с другими данными, другим объёмом памяти и т. д. было как-то так, то это не значит, что и в твоём случае будет так же. Остаётся только тестить.

aureliano15 ()
Ответ на: комментарий от gobot

Есть проект, в котором несколько таблиц с не менее 100к записей на каждую и обновление информации я стараюсь делать как можно более точным запросом (ORM, get(id)), потому что выборка даже по составному ключу уже заметно медленнее работает, а если выбрать всё и потом фильтровать — это будет просто ад.

conformist ★★★ ()

Код пишется, чтобы его человеку потом понять. Открыл код, а там «SELECT * FROM foo;» и иди трать время, отвлекайся, смотри, что за таблица и что за поля в ней. А если написано «SELECT name, address FROM foo», то и ходить никуда не надо, сразу знаешь, что прилетит и что с этим делать.

keir ()

Этот вопрос похож на «нужны ли в БД другие индексы, кроме primary key, и другой пользователь, кроме root@localhost?» примерно с таким же ответом. Дома, на локалхосте, с маленькими таблицами и лёгкими, простенькими запросами, для одного единственного девелопера с одним единственным нетребовательным и снисходительным пользователем (самим собой) - да плевать! Но как только задача становиться чуть менее тривиальной - без них не обойтись. Звёздочка собой скрывает чувствительные поля, поля с разных таблиц с тем же названием и, возможно, недавно поломанную схему. С ней не станет работать запросы для таблиц, где есть ограничения по доступу к её столбикам. В конечном итоге, звёздочка не даёт возможностей и ясности, а наоборот - сильно ограничивает и запутывает, так что её лучше не использовать.

anonymous ()

Насколько это влияет на производительность?

В контексте mysql не влияет. А если взять column oriented databases, как например vertica, то влияет. В обычных реляционных БД данные и все построенные индексы указывают на конкретные строки таблицы, если нашел строку то одинаково что считать все колонки, что только одну. В column oriented databases каждая колонка имеет свои индексы и выборка из множества колонок похоже на запрос к множеству таблиц в обычно БД.

Почему перечисляют:

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

2. Избегать неоднозначностей в коде, нужно дать понять какие колонки необходимы для запроса. Например будет задача избавится от legacy колонок, данные из которых уже переехали в другую таблицу. Если будут писать (select *) то человеку взявшему на себя этот тикет по удалению колонок, придется анализировать все запросы к затронутым таблицам и логику за ними.

Aber ★★ ()