очень резко сужает наши возможности. И мы никак не сможем это требование
обеспечить если будем вульгарно прыгать с одного компиллятора на другой (MinGW)
или спорить о С++ или C.
Я думаю Александр полностью ответил на вопрос. Стандартное средство - wget. И оно работает для 80% сайтов. Должно работать.
Другое дело что современные сайты из всех сил сопротивляются скачиванию. И поэтому для них
очень трудно искать какой-то стандартный подход. Задача еще осложняется анти-капчей и прочими
вопросами которые просто wget не решает.
Если например смотреть в сторону Селениума и прочих браузеров которые эмулируют полноценную интеракцию - то даже они требуют ручной доводки и конфигурирования. И это уж точно никак не пользователский подход. Это скорее какая-то разработка.
Вобщем я кликаю что решение вопроса есть. И можно дальше ничего и не искать.
zilevsky, некоторые небольшие кусочки бинарных данных (токены, ключи, сертификаты) хранят в базе в виде строк в кодировке Base64 или BinHex. Это удобно. Они обычно не больше 4к. И есть удобство кидать их через клипборд во время разработки и тестирования.
Но если данные большие и будет нагрузка (много пользователей захотят читать много документов) - то надо хранить в дисковых хранилищах. А в базе просто класть Url на файлик который лежит где-то там.
Вообще база с точки зрения суммарной стоимости владения - всегда дороже чем дисковое хранилище. Базу надо беречь и не пихать в нее нереляционные данные. Исторически базы были созданы для хранения коротких строчек и чисел. И если в них класть блобы - то таблица всегда деградирует по производительности. И бэкапы становятся безумно долгие и малополезные.
Не напасёшся правил. А если он потом захочет более сложную проверки на больше-меньше?
Проще арифметику проверять там где появляется арифметический контекст.
Double.parseDouble(operand)
если результат этого > 10.0 и т.д. - то бросать RuntimeException.
А автор большой лентяй и очевидно что чужую лабу сдает. Позор!
Не знаток оптимизаций в mysql, но если у нас работает inner join с 5 таблицами то нам надо форсировать такой план соединения при котором самое селективное соединение выполнится в первую очередь. Как управлять порядком соединения в mysql - я не знаю. Есть ли там хинты? Можно ли скобочками или inline views создать видимость порядка.
Как ускорить тут order-by - непонятно. Вообще сомнительно что его можно оптимизировать. Проще пересмотреть ТЗ и решить что этого не надо делать.
Sanger, отследить его скорее всего невозможно. Это софт back end. Он работает пост-фактум. Как биг дата. По логам сетевых событий скорее всего.
Как он работает я не знаю. Но он скорее всего анализирует как ведут себя люди. Как они кликают мышкой и нажимают кнопки. После этого строиться модель человека-игрока. Например когда он кликает - интервалы между кликами распределены по закону Гаусса. Совокупность рандомных факторов. Сумма времен.
Твой робот будет лупить либо линейный закон. Либо строгий период. Пик. По этим признакам можно видеть где чел и где робот.
Но это так. В общих чертах. На самом деле анализ может быть более глубоким.
pfemidi, ты знаешь, когда я был студентом - как-то на лекции по вышке (математика) услышал голос с галёрки
- А зачем нужна эта функция?
Доцент который нам читал про анализ ни на секунду не смутившись ответил
- А зачем она не нужна?
очень резко сужает наши возможности. И мы никак не сможем это требование
обеспечить если будем вульгарно прыгать с одного компиллятора на другой (MinGW)
или спорить о С++ или C.
Нужна ясность.
Давайте корректно тегнем вопрос для начала.