SELECT `i`.*
FROM `items` AS `i`
JOIN `properties` AS `p1` ON `p1`.`item_id` = `i`.`id`
AND `p1`.`name` = 'цвет' AND `p1`.`value` = 'чёрный'
JOIN `properties` AS `p2` ON `p2`.`item_id` = `i`.`id`
AND `p2`.`name` = 'размер' AND `p2`.`value` = 'XXXL'
Про что? Про HTTPS, думаю, смысла не имеет здесь что-то объяснять, это и так хорошо описано.
Про своё шифрование:
- При первом подключении клиента сервер генерирует пару ключей RSA
- Открытый ключ посылается клиенту
- Клиент генерирует случайный сеансовый ключ
- Клиент шифрует открытым ключом сеансовый ключ, логин и пароль и отсылает их на сервер
- Сервер дешифрует данные закрытым ключом и проверяет учётную запись
- Если всё в порядке, то дальнейший обмен идёт с шифрованием данных симметричным алгоритмом с открытым ключом
- По истечении срока действия сеансового ключа сервер перестаёт отдавать данные, на каждый запрос отвечая требованием реконнекта
65536: Вообще-то это операция унарного минуса (смена знака числа). Вполне логично, что она не действует на строки, если строку нельзя перевести в число. Но такая операция - это уже не значение колонки, а выражение, а в MySQL индексы по выражениям не работают.
nkorobkov: Нет, расписание всё равно должно быть отдельной таблицей. Например предприятие может в понедельник-четверг работать с 9 до 18, в пятницу с 9 до 15, а в выходные вообще не работать или в пн, ср, пт работать до обеда, а во вт, чт, сб - после обеда.
Исключение - да, праздничные, предпраздничные и другие даты, когда расписание работы меняется.
Sector567: Да примерно то же самое, только надо сначала выделить новый массив (malloc), того же размера, что и исходный, передать его в функцию и write установить на этот массив.
Всё-таки задержка на восемь миллионов секунд...