Во избежание путаницы полей (если встречаются поля с одинаковыми названиями) используйте в запросах оператор AS: «SELECT table1.id as id1, table2.id as id2″. Это поможет избежать ошибок в запросе (например, если не указана таблица, а поле с таким названием есть в нескольких запрашиваемых таблицах, mysql выдаёт ошибку), а так же вы избежите недоразумений при работе с полученными данными (echo $row[«id1″] писать гораздо проще, чем $row[$x]).

• Во избежание путаницы полей (если встречаются поля с одинаковыми названиями) используйте в запросах оператор AS: «SELECT table1.id as id1, table2.id as id2″. Это поможет избежать ошибок в запросе (например, если не указана таблица, а поле с таким названием есть в нескольких запрашиваемых таблицах, mysql выдаёт ошибку), а так же вы избежите недоразумений при работе с полученными данными (echo $row[«id1″] писать гораздо проще, чем $row[$x]).
• Данные типа DATE, TIME, DATETIME и TIMESTAMP можно форматировать с помощью функции date_format (см. руководство по mysql). Используйте его, и не форматируйте данные через php — это не просто «самодеятельность», а ещё и растрата системных ресурсов.
• По возможности минимально используйте LEFT JOIN для объединения таблиц. Это весьма трудоёмкая операция для базы данных.
• Там, где можно, используйте идентификаторы — выборка данных при указании ключевого поля происходит быстрее, чем при указании обычного.
• Вместо «WHERE id=1 OR id=3 OR id=232″ можно использовать встроенную функцию IN: «WHERE id IN (1,3,232)».
• Если нужен текстовый поиск, осторожней со знаком «%». Во всяком случае, запросы типа somefield LIKE ‘%a%’ лучше не делать — опять же слишком трудоёмкая операция. По крайней мере, надо фильтровать слова и отрезать те, которые короче 3 символов.
• Используйте минимум необходимых полей в запросе. «SELECT * FROM sometable» выполняется медленнее, чем «SELECT id FROM sometable», тем более если в таблице много данных. Для подсчёта количества строк в таблице вообще (или подпадающих под некоторое условие) достаточно одного поля.
• Разбивайте данные на страницы, используя оператор LIMIT. Это экономит время выполнения запроса и уменьшает объем страницы, которую получает пользователь.

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

• Старайтесь не допускать внесения в базу данных символа одинарной кавычки («‘»), поскольку это служебный символ запросов БД. Перед внесением в базу поле можно обработать функцией str_replace: $somefield = str_replace(«‘», «‘», $somefield);

К тому же это лишний барьер на пути взломщиков вашего сайта. Пример «взлома» простой:

mysql_query("UPDATE users SET password=PASSWORD('$passwd') WHERE login='$login'");

Если кавычку не обработать на входе, злоумышленник может в качестве логина сунуть строку «vasya_pupkin’ OR login LIKE’%». В базу данных залетит запрос: mysql_query(«UPDATE users SET password=PASSWORD(‘$passwd’) WHERE login=’vasya_pupkin’ OR login LIKE ‘%'»); То есть все пароли будут одинаковые. Это только один пример. Итак,

• Обрабатывайте данные, получаемые из адресной строки или из формы, и приводите их к нужному типу во избежание ошибок и «взломов» сайта. (ещё пример: если требуется идентификатор, то есть целое число, надо обработать его с помощью intval: $id = intval($id)).

Запросы на вставку строки (INSERT)

• Поле идентификатора вставлять не нужно. На это есть свойство поля AUTO_INCREMENT.

Забавно читать, как в форуме пишут:

— Как мне быть с генератором случайных чисел?! неправильно работает!
— А зачем тебе?
— Да в базе id использовать…

В общем, не надо самодеятельности.

• Если в поле формата DATE, TIME, DATETIME или TIMESTAMP надо вставить текущее время, используйте встроенную в mysql функцию NOW: «INSERT INTO vote (ip, date) VALUES ($REMOTE_ADDR, NOW())»
• Хранимые в базе пароли лучше прикрыть функцией php md5: «INSERT INTO user (login, pass) VALUES (‘$login’, «. md5($pass). «)» «SELECT * FROM user WHERE login=’$login’ AND pass=». md5($pass)

Советы, кажется, уже исчерпаны. Напоследок. С недавних пор я стал думать, что при написании скриптов, работающих с БД, надо ориентироваться не только на глупого и шаловливого посетителя, но и на криворукого администратора. Даже если мы внимательно будем следить за текстом, который вставляем в текстовое поле (одинарные кавычки не писать, делать их автозамену в Word-е, белое не носить), вероятность попадания служебных символов в запрос ненулевая.

Источник:  internet-technologies.ru