Bodrosh, Во-первых, не количество вхождений, а позицию вхождения. Во-вторых, если элемента нет в строке, то возвращается 0, что эквивалентно FALSE, если есть - то не 0 (TRUE).
Sienore, Получить можно в PHP, и в JS. Но для подписи вам надо шифровать не сам файл, а только хэш от него.
На мой взгляд, оптимальная последовательность будет примерно следующей:
- Клиент передаёт файл на сервер.
- Сервер записывает файл в базу, вычисляет хэш от него, передаёт хэш на клиент.
- Клиент шифрует хэш закрытым ключом, передаёт полученную подпись на сервер.
- Сервер дешифрует подпись открытым ключом, привязанным к пользователю, удостоверяется, что хэш правильный, записывает подпись в базу.
HadjyGit, У вас же права на участок могут меняться, соответственно если нужна история владения участком, то придётся держать отдельную таблицу. И, возможно, учитывать ещё и долю владения.
`owners` (`area_id`, `user_id`, `acquisition_date`, `loss_date`, `share`)
yuriy2, Если я правильно понимаю документацию, то Using where присутствует всегда, кроме случаев, когда в запросе явно указано, что нужно взять все строки (то есть отсутствуют WHERE, JOIN, HAVING и т.п.).
Об использовании составного индекса здесь прямо говорится, что используется только непрерывная левая часть индекса.
Эврика! Здесь говорится, что в случае покрывающего индекса (а здесь именно такой случай) записи индекса используются для ускорения доступа к данным при переборе, так как записи индекса, в общем случае, занимают меньше места и расположены компактнее, чем записи самой таблицы.
Неправильно. Часть составного индекса используется, только если она совпадает с началом ключа.
В вашем примере WHERE a=1 будет использовать индекс, WHERE a=1 and b=2 тоже, а WHERE c='text' - не будет.
Вячеслав Барсуков, Значит берёте нужную часть, изучаете, смотрите, почему не работает, восстанавливаете. Реверс-инженеринг занятие не из простых.
Либо просто обращаетесь к автору и просите исходники.
Вячеслав Барсуков, Нет, файлы не склеили, а запаковали в сборку с помощью webpack.
Большую часть проще скачать из источников, благо все ссылки там присутствуют. Ну а остальное - только скопипастить нужный фрагмент и вручную восстанавливать имена функций и переменных.
evgeniy_lm, В графическом представлении интеграл - это площадь. Вспомните, как даётся определение интеграла через трапеции. Теперь возьмите, например, трапецию, нижняя сторона которой - ось X, боковые стороны x = 0 и x = 10, верхняя - y = x/2+10. Посчитайте площадь трапеции, сначала по стандартной формуле, затем через интеграл (x/2+10)dx от 0 до 10. Удивитесь, что результат получился тот же самый.
Когда контур задан ломаной линией (то есть координатами концов отрезков), то обычный интеграл по нему можно представить в виде суммы площадей трапеций, интеграл относительно точки - в виде суммы площадей треугольников.
Конечно, если исходные данные представлены исключительно в виде картинки цвет(x, y), то интегрирование не поможет, но там и ваш метод суммирования углов даст дикую погрешность.
evgeniy_lm, А в чём проблема? Если контур задан ломанной линией, как здесь, то интегрирование относительно точки сводится к вычислению суммы площадей треугольников, с учётом направления отрезка.
