FanatPHP

1. Монга как раз решает проблему таблицы связей. Собственно, потому ее тебе и рекомендуют, что она решает ту самую задачу, что ты сейчас описал - избавляет от связей. В ней можно тупо писать "цвет: красный, обогрев: есть, минимальная температура охлаждения: 16" - вот примерно так запрос и выглядит, в виде JSON. Но тут могут быть проблемы с индексами (индексируемых полей тысячи, столько индексов не напасешься), а перебором много не наищешь.

2. И тут приходит на помощь свинкс.
Самый тупой вариант - генерировать т е к с т. Сфинкс же полнотекстовый поиск? Ну вот и нагенерировать текст, такой же, как я выше написал, в котором перечислены все параметры. Ищет замечательно. Для более продвинутых вариантов гуглить sphinx faceted search

Выставляй переменную окружения env
В перле это должно быть просто, в РНР - getenv()

Смысла нет.

Проблема начинающих защищателей, которых ты начитался, состоит в очень скудных знаниях об SQL инъекциях. И свои советы они строят исходя из этих самых знаний. Состоящих из ровно одного примера про Бобби-фейсом-об-тейбл.

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

Поэтому заниматься такой ерундой, как разделение прав, не нужно. Нужно соблюдать одно очень простое правило при работе с БД - ЛЮБЫЕ данные должны попадать в запрос только через плейсхолдер - и проблема инъекций решена.

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

Есть несколько бд, которые используются разными источниками (сайт1 -> бд1, сайт2 -> бд2, и т.д.)

Сдается мне аффтар, что ты фантазируешь. То у тебя сайты, а потом уже вдруг таблицы.
Разумеется, такая система нежизнеспособна, и я сильно сомневаюсь, что она существует в реальности. Поэтому лучше бы тебе отказаться от этой фантазии и делать по-человечески.

habrahabr.ru/post/114947

habrahabr.ru/post/112953

Только переменная должна быть одна. Называется "массив":

$a[0]['img'] = "1.jpg";
$a[0]['title'] = "Фотография Дома";
$a[0]['descr'] = "Фасад дома";
$a[1]['img'] = "2.jpg";
$a[1]['title'] = "Картинка 2";
$a[1]['descr'] = "Описание от второй картинки";

и т.д.

Сначала надо понять, что XML - это формат не для хранения, а для передачи данных.
После этого сохранить данные в более подходящем формате и генерировать XML по запросу.

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

Как записать в $_SESSION значение $_GET?

$_SESSION['peremennaya'] = $_GET['peremennaya'];

Вопрос в том, как не уничтожать данные в переменной.

Не уничтожать их.

Перечитай мой ответ, потом соберись с мыслями и попробуй сформулировать свой вопрос так, чтобы на него мог ответить не только капитан Очевидность

По по вопросу всегда видно - понимает ли автор, что он делает.
В данном случае автор уверен, что причина в джойне.
Что говорит нам об общей осмысленности мероприятия.
И уровне автора.
И необходимости отвечать на вопрос буквально, в "лоб".

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

Случай здесь очевидный.
В таких случаях надо не уговаривать, "ну миленький, а может пересмотришь структурочку базочки данных? Нет? Ну нет - так нет. Тогда поможем тебе ваять этот треш и угар дальше...".

В таких случаях надо бить молотком по голове, объясняя, что наличие таблиц `members` и `members_two` содержащих одни и те же поля, и ТОЖЕ НУМЕРОВАННЫЕ - это продукт адовой неграмотности, и непонимания, что такое база данных вообще.

Объясняя, что за такие вещи этот несчастный школьник будет гореть в аду, и что таблица должна быть одна, и в ней должно быть поле, в котором ставится признак "two". А все нумерованные поля v1 v0 должны писаться в отдельную таблицу, из трех сполбцов - member_id, v, значение

Три ответа и куча лайков.
Что характерно, если тех же самых людей спросить, надо ли хэшировать пароли на сервере - все дружно, строем и хором ответят - НУЖНО!

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

Это квинтессенция подобныйх сайтов. Ответ почему-то всегда даётся самый буквальный. При этом вопрос никогда не подвергается сомнению или хотя бы минимальной проверке на осмысленность. Такое ощущение, что отвечающие воспринимают вопрос как экзамен что ли? Или как челендж - ответить любой ценой, пусть даже и неимоверных извращений и ГАРАНТИРОВАННЫХ граблей в будущем. Или - как сейчас - ценой СНИЖЕНИЯ защищенности! Но зато ответ буквальный. И так не только здесь - так практически в любом ответе. Ну никогда ни у кого не твремени задуматься над вопросом - все торопятся отвечать.

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

Возможно, одна из причин в том, что в голове у отвечателей отсутствуют реальные знания, а стоит органчик, в который записано несколько прочитанных когда-то ответов. И один из этих ответов выстреливается сразу после прочтения заголовка - даже не углубляясь в текст вопроса. Таких "отвечателей" надо гнать поганой метлой. Пусть самоутверждаются в другом месте. Тем же, кто хочет ответить, рекомендую придерживаться правила:

Перед тем как отвечать, НАДО СНАЧАЛА ПОДУМАТЬ. Посчитать на ход вперед - "а что будет, если сделать, как я советую?" Посчитать на ход назад - "а зачем ему нужно это? Не похож ли этот вопрос на мой собственный, который я когда-то задавал от недостатка знаний?" И попробовать ответить так, чтобы РЕАЛЬНО помочь спрашивающему, а не просто выдать зазубренный ответ.

Возвращаясь к вопросу: нет, нельзя без SSL. Хэширование на сервере важнее.
Можно эмулировать SSL для передачи пароля, но куда проще воспользоваться готовым механизмом. На дворе 2014 год, все основные сайты перешли на шифрование всего трафика вообще. Пора переставать бояться SSL.

Минусы стандартные.

• На миллион файлов одного уровня вложенности хватит, но на десяти уже начнутся проблемы, когда в каждом каталоге будет по несколько десятков файлов. Я помню про "не больше ляма", но "640К памяти хватит всем...", ога.
• Заведомо неуникальные имена файлов пользователей. Не забыть прибавлять к хэшируемой строке микротайм.
• Следить, чтобы у хэшируемой строки не было общего префикса (скажем, полного пути к файлу на диске) - тогда первые символы хэша будут распределяться неравномерно, и неравномерно заполнять каталоги.

ТЕБЕ
ЭТО
НЕ НУЖНО

Фильтрация от опасных символов.

Можно не проверять. Сайт дырявый.