Как лучше вставлять переменную в запрос?

Статус
В этой теме нельзя размещать новые ответы.
И веркор атак может быть и без звездочек..Просто * это огромная дыра...Вы выгружаете всю таблицу...Зачем? Это поле для маневров...А дал наводку, а не мануал или панацею..
Если таблицы действительно очень большие и колонок очень много, то перечисление этих колонок не является дурным тоном, и проверку на содержимое тоже еще никто не отменял....
Для просмотра ссылки Войди или Зарегистрируйся
Для просмотра ссылки Войди или Зарегистрируйся
 
И веркор атак может быть и без звездочек..Просто * это огромная дыра...Вы выгружаете всю таблицу...Зачем? Это поле для маневров...А дал наводку, а не мануал или панацею..
Если таблицы действительно очень большие и колонок очень много, то перечисление этих колонок не является дурным тоном, и проверку на содержимое тоже еще никто не отменял....
Для просмотра ссылки Войди или Зарегистрируйся
Для просмотра ссылки Войди или Зарегистрируйся
Вы просто немного не понимаете о чем говорите, а именно сложности вызывает слово Injection в SQL Injection.

Сама по себе звездочка - вполне безопасна и не несет никакого вреда. Это никакая не огромная дыра и никакое не поле для маневров.

Сейчас вы из-за отсутствия аргументов кинулись в какие-то крайности, если у вас 150 столбцов - тогда вы будете перечислять их, если 5 столбцов - какой смысл? А если у вас ActiveRecord, тогда что? Там в любом случае надо выбирать все что есть и тут звездочка будет вам только в помощь. Зачем гонять на сервер запросы со 150 перечисленными полями, если выбирать все надо? Вы теряете производительность на пустом месте, величина запроса увеличивает сетевую нагрузку, перечисление - нагружает механизм разбора запроса перед исполнением в БД и т.д. А про скорость разработки я вообще молчу, сколько вы будете формировать такие запросы?

Звездочка - это не выборка всей таблицы, это всего-лишь предфинальное формирование результата (финальное - это ORDER). Не важно что вы напишете в SELECT, база данных все равно будет оперировать всеми столбцами гигантских таблиц. Не важно, select id from у вас там или select * from. SELECT работает перед ORDER BY, но после FROM, JOIN, GROUP, HAVING, WHERE.

Теперь поговорим об инъекции. Сама по себе инъекция не возможна при качественной фильтрации данных и работает она на более ранних этапах, чем SELECT. И если у вас есть id='$_GET['id']', то злоумышленника будет интересовать вовсе не то что у вас в селекте, он пришлет вам айдишник вида: 0';SELECT * FROM user_credit_cards;/*, а перед этим 0';SHOW TABLES;/*. Таким образом на сервере у вас уйдет
Код:
SELECT * FROM users where id='0';SELECT * FROM user_credit_cards;/*' and password=ноэтоуженеважноибокомментарий.
И заметьте, никакая ваша звездочка в этом запросе не участвует и никого не интересует.
 
Последнее редактирование:
activerecord это по-моему rails, в котором я вообще не шарю...
Что касается производительности но не думаю что выгружать 150/200 и 200/200 будет одинаково по времени
А если нужно вернуть всего десяток колонок?
Да нужно фильтровать все что после where, и сама по себе * не так уж и опасна, но раскидываться данными, которые не используются в данном запросе....
 
activerecord это по-моему rails, в котором я вообще не шарю...
Что касается производительности но не думаю что выгружать 150/200 и 200/200 будет одинаково по времени
А если нужно вернуть всего десяток колонок?
Да нужно фильтровать все что после where, и сама по себе * не так уж и опасна, но раскидываться данными, которые не используются в данном запросе....
ActiveRecord - это паттерн, так что это и Rails (RoR) и PHP (Yii) и Python (Django) и любой другой язык программирования.

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

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

В среднем, стоимость дня работы программиста от 5000 до 15000 руб. Стоимость 8Гб планки оперативной памяти в сервер - 5000 руб.
 
Вместо звезды перечисляют поля только когда рассчитывают на покрывающие индексы. Остальное - по барабану, кроме каких-то экзотических случаев когда в выборке реально много BLOB-данных. Но тут опять же умудренные опытом люди такие данные выносят в отдельные таблицы и джойнят по необходимости.
 
Вместо звезды перечисляют поля только когда рассчитывают на покрывающие индексы. Остальное - по барабану, кроме каких-то экзотических случаев когда в выборке реально много BLOB-данных. Но тут опять же умудренные опытом люди такие данные выносят в отдельные таблицы и джойнят по необходимости.
Не-не-не, SELECT никак не индексы влиять не может, он сильно позже исполняется. Для форсирования индекса используется либо USE INDEX, либо FORCE INDEX, но идут они уже после FROM.
 
Если все есть в покрывающем индексе, идет выборка сразу из индекса без обращения к реальным данным - я про это.
 
  • Нравится
Реакции: BaBL
Это только когда схема устоялась и уже никогда не будет меняться (что редко).
Всегда может появиться третий вариант. Пол: М:Ж. Добавили регистрацию юр лица => пол + "не определен". Оптимизация производительности, меньше места? Поверьте, есть куда более серьезные проблемы на уровне схем. А вот ALTER TABLE на большой базе, рабочей, когда все-таки откажемся от BIT - хорошее удовольствие :)
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху