mysql_set_charset('кодировка');
ALTER TABLE tasks ADD INDEX (status,price);
Судя по документации к GAE, там надо добавить субдомен с именем * в панели управления.
После этого все запросы будут приходить на основной веб-сервер, при этом конкретный субдомен можно будет получить из $_SERVER['HTTP_HOST'].
Если речь именно о компиляции, без запуска, то как-то так?
<?
$commands = [
'ls' => 'ls -la',
'basic' => '/path/to/basic param1 param2',
'java' => '/path/to/java param param',
];
if (isset($_FILES['file']) && !$_FILES['file']['error'] && isset($commands[$_POST['lang']]))
{
$comm = $commands[$_POST['lang']];
$file = $_FILES['file']['tmp_name'];
echo "<pre>";
echo `$comm $file 2>&1`;
echo "</pre>";
}
?>
<form enctype="multipart/form-data" method="POST">
<select name="lang">
<?php foreach ($commands as $key => $void):?>
<option><?=$key?></option>
<?php endforeach ?>
</select><input name="file" type="file" /><input type="submit" /></form>
Не очень понятны эти идеи про разность индексов. Да, индекс по четырем байтам целочисленного поля получится меньше и за счет этого быстрее, чем индекс из первых, скажем, 20-и символов текстового. Но разница будет не настолько значительная.
Для компьютера и число и строка - это набор байт. Что конкретно в эти байты записано - ему всё равно. Поиск по упорядоченному набору байт будет производиться одинаково.
Не стоит заранее переживать за производительность. От этого одни проблемы.
К "любознательности" этот вопрос не имеет отношения. А думать, что это каким-либо образом относится к SQL - прямая дорога к инъекции.
А имеет - к валидации данных и, частично, к юзабилити и СЕО.
Пробел - символ нерелевантный, его могут тримать автоматом. Так что буду говорить о "частично валидных" урлах в целом. Учитывая, что урлы руками сейчас никто не набирает, а поисковики могут плохо относиться к существованию одной и той же страницы с разными урлами - я бы не пропускал, отдавал 404.
Скорость тут не играет никакой роли. В частности, операционная система умеет кэшировать часто используемые файлы, и скорость диска оказывается совсем не при чем.
А вот подход с разделением на хидер и футер - неправильный и давно устарел.
Делить страницу надо не на хидер и футер, а на код и отображение. Потому что:
- во-первых, отдельно хидер и футер редактировать неудобно.
- во-вторых, иногда нам надо выполнить некоторый код ДО вызова хидера.
- в-третьих, у "середины" тоже должен быть свой шаблон - о чем многие начинающие разработчики забывают
В итоге страница должна собираться из трех частей:
1. Логика приложения. Должна выполняться ДО любого вывода, и хидера в том числе.
2. Общий шаблон сайта, который содержит в себе и хидер и футер. Вызывается после того, как отработала логика.
3. Шаблон конкретной страницы, который включается в общий шаблон сайта.
При такой структуре не составит никакого труда вместо страницы вывести сообщение об ошибке (при ошибке) или поменять формат вывода с HTML на JSON. Не говоря уже о смене дизайна.
Вариантов реализации может быть масса, пример самой простой, на чистом PHP, можно посмотреть здесь: http://www.phpfaq.ru/tpl#example
ini_set('session.bug_compat_warn', 0);