Либо нужно вычислить эту строку eval-ом, тогдла в нее подставится переменная, либо хранить запрос с плейс-холдерами(штуки типа ? или ?s или :param1 - смотря, чем пользоваться), препарировать(prepare), биндить параметры и екзекутить.
Подробнее гугл-> sql prepare execute.
А вообще хранить в базе sql запросы - немного глупо, по-моему
но вообще это не будет быстро работать. Чтоб работало быстро, надо поделать всякие извращения типа периодического перенумеровывания таблицы или еще чего-нибудь
Ну да, я оговорился о том, что самое простое - без степеней - умножение и сложение.
Не думаю, что задача сложнее и в примере этого нет. Если сложнее, то тут простым описанием не напишешь
Это довольно сложная задача. Даже если кроме умножения и сложения в строке ничего нет. Если там показательные уравнения, логарифмы и производные - то это уже супер сложная задача.
Если плюсы и умножения(без возведения в степень), то:
1. Раскрываем скобки
2. Переносим все слагаемые с иксом влево, без икса - вправо
3. Выносим Х за скобку
4. Делим правую часть на скобку возле икса.
Самое сложное - первый пункт. Скорее всего нужно построить синтаксическое дерево. Его узлами будет такая структура:
struct {
operation;
operand1;
operand2;
}
operation - сложение или умножение, операнды - это операнды. Они могут быть как числами, так и такими же структурами.
В PHP это удобно ассоциативным массивом реализовать.
Как его формировать? Рекурсивно. Функция tree():
- Скобка открылась - передаем дальнейшую часть в функцию tree();
- Скобка открылась - выходим из функции.
- Число - нашли операнд - +-/* - нашли оператор. Изначально всё выражение можно обернуть в скобки перед первым вызовом функции для общности.
Теперь можно раскрывать скобки - от самого нижнего уровня дерева. Раскрыли скобки самого нижнего уровня, предпоследний уровень стал нижним и так до верху.
Теперь получилась простая для разбора строка, с которой уже можно работать функциями обработки строк. Берем коэффициенты перед иксом и формируем из них делитель для правой части.
ВэйДлин пишет:
Студент колледжа информационных технологий
не МГКИТ?)
PS Надо бы сделать чтоб один и тот же топик был всегда доступен по одной и той же ссылки, куда бы его не переносили. Во-первых, эта ссылка шлется автору топика при создании темы. Во-вторых, индексируется поисковиками. В-третьих, пока я писал этот длинный ответ, модератор перенес тему и вместо сохранения поста я увидел "такой темы не существует" - потмоу что ссылка поменялась. Хорошо, что есть файрбаг и я смог вытащить то, что писал. Иначе я бы расстроился
/^[1-9+-]\d+$/ (Добавление)
Ваша регулярка тоже правильно написано, в ней нет ошибки. Если только "явлаются ли ВСЕ следующие символы цифрами от 0 до 9", то надо заякорить на конец строки вот этой штукой $
Когда вот в таком виде (!a() && !b() and !c()), то никак - какими бы там приоритетными не были && и and, когда других операторов нету, они все равно выполнятся слева на право.
А вот если есть, например плюсы или присваивание, то разница заметнее. Например
$a = true and false; // $a будет true
$b = true && false; // будет false
то есть с начало будет проверено на истину переменная $b и $c и затем будет проверена переменная $a
Во-первых, пишется "сначала". А во-вторых на самом деле сначала будет проверена переменная А, потом Б и Ц.
Приоритет у and ниже, чем у &&, но это сказывается не так.
А еще и and, и && прекращают выполняться как только накнутся на первый false, так что объяснения примеров некорректны.
Перечитал еще раз вопрос
Oleh пишет:
только если все три переменные имеют пустое значение, а не одна или две из них.
Ну тогда всё правильно у вас написано. В чем проявляется "ошибка" ? И что до условия происходит с А, Б и Ц? (Добавление)
Самогонщик пишет:
Ты о ленивости?
Да, о ленивости тоже. Мне сначала показалась, что его ошибка с приоритетами более неправильная, чем есть на самом деле. На самом деле она не большая)
Третий запрос, если должен найти категории, у которых нет дочерних категорий, то ему нужны те же индексы по id и parent_id.
Возможно, что его стоит переписать так:
SELECT ca1.name
FROM category ca1
LEFT JOIN category ca2 ON c1.id = ca2.parent_id
WHERE ca2.id is null
Тогда он сможет (если СУБД решит использовать merge join) выполниться за N+N операций (Добавление)
romanov пишет:
На самом деле второй запрос выглядит так:
romanov пишет:
Выбрать все категории нижнего уровня т.е. не имеющих детей.