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, А в чём проблема? Если контур задан ломанной линией, как здесь, то интегрирование относительно точки сводится к вычислению суммы площадей треугольников, с учётом направления отрезка.
Добавлю, если JOIN проводить сразу по нужным условиям, то может оказаться, что после первого же JOIN'а у вас стало не триллион, а всего тысяча записей.
blabs, Если в JSON только хранение, то для БД это просто текстовое поле. Там может быть хоть JSON, хоть XML, хоть сериализованные данные из PHP, хоть ваш собственный формат, базе всё равно. Она получила строку, вернула строку.
А по времени такой способ быстрее, чем слияние таблиц.
