select sum(number), country_id from table group by country_id;select sum(number), city_name, country_id from table group by country_id;
if (страна_не_определена) {
Определяем страну
}
return $next($request);
Изначально отказаться от стандартных СУБД (like MySQL), ибо в базу ежесекундно (а то и чащще!) нужно скидывать текущие значения коэффициентов с тысяч событий. (К примеру - в субботний вечер в час пик на разных конторах транслируется 200 событий на разные виды спорта. Нужно например парсить 30 контор. 200*30 = 6 000 трансляций. А контор, необходимых для сканирования - гораздо больше 20). Конечно же коэффициенты обновляются не каждую секунду. Но на динамичных видах спорта - очень часто. И нужно рассчитывать на то что в такую базу будет прилетать 6000 запросов обновления в секунду.
Продолжение п.1: вместо стандартной БД использовать "In memory DB", т.е. что то, что висит в оперативке и обновляет данные максимально быстро. Сохранность данных здесь вообще не важна, ибо через 3 секунды актуальность данных уже пропадает.
С одной стороны в эту базу будут писать данные парсеры, с другой стороны ежесекундно к этой базе ежесекундно будет обращаться функция построения итоговой таблицы тех самых арбитражных ситуаций. И уже к этой итоговой таблице будет обращаться вебсервер и по выбранным фильтрам пользователя будет показывать ему таблицу интересующих его вилок/валуев (тех самых арбитражных ситуаций). Кстати - у пользователя будет открыта страница, которая будет рефрешиться тоже раз в секунду. А учитывая что пользователей может быть тысяча - то и таких запросов тоже будет прилетать 1 000 в секунду.
Что касается самого парсинга. Раньше каждую контору парсили по своему: какая то контора обновляла данные через сокеты, какие то - обычными http-запросами. И все существующие подобные сканеры посылали свои запросы через сокеты, или формировали свои http запросы. Но сегодня это все уже работает плохо, ибо конторы защищаются от парсинга разными методами. И самый простой и самый универсальный способ парсить данные - это парсинг браузером. Т.е. вы просто открываете в браузере страницу события и парсите ее. Но конечно же - за такую универсальность придется заплатить ресурсами. Каждая такая страница будет занимать мегабайты в оперативке. Предположим одна страница в среднем занимае 20 МБ оперативки. Тогда предполагаемые 6 000 открытых страниц займут 6 000 * 20 МБ = 120 000 МБ = 120 ГБ оперативки. Конечно, это нужно делать на
DB::table('MYTABLE')->insert([
'id' => $id,
'description' => mb_substr($description, 0, 255)
]);For STRICT_TRANS_TABLES, MySQL converts an invalid value to the closest valid value for the column and inserts the adjusted value. If a value is missing, MySQL inserts the implicit default value for the column data type. In either case, MySQL generates a warning rather than an error and continues processing the statement. Implicit defaults are described in Section 11.6, “Data Type Default Values”.
Среди работников милиции провели тест на сообразительность. Суть теста: в металлической пластине вырезаны отверстия различной формы (квадрат, круг, треугольник и т. д. ), в них нужно вставить соответствующие металлические тела. По результатам теста работники милиции разделились на две группы:
1. Тупые.
2. Очень сильные.
//Текущий
dump(Auth::user()->roles);
//Любой другой
dump(User::find(1)->roles);
// в вашем случае
$users = User::with('roles')->get();
foreach ($users as $user) {
dump($user->roles);
}//return $this->belongsToMany(User::class, 'role_user', 'role_id', 'user_id');
return $this->belongsToMany(User::class);
