Предполагаю, что не int из-за того, что там хранят дату в виде целого числа наподобие 20160523222415 (ГГГГММДДччммсс). Но почему тогда не timestamp — хз. Возможно наткнулись на то, что индекс по timestamp в огромных таблицах не всегда эффективно работает в MySQL.
Это валюта, в которой хранится сумма. Конструктора просто не хватает в примере. Что-то типа такого должно быть
final class Money
{
const CURRENCY_USD = 1;
private $amount;
private $currency;
private function __construct($amount, $currency)
{
$this->amount = $amount;
$this->currency = $currency;
}
public static function USD($amount) {
return new static($amount, self::CURRENCY_USD);
}
public function getAmount()
{
return $this->amount;
}
public function add($amount)
{
return new self($this->amount + $amount, $this->currency);
}
}
Это принятое обозначение, чтобы сослаться на метод класса, не важно статический он или нет, вот например, тут так делают. Или я совсем туплю под вечер? :)
У каждого подхода свои преимущества и недостатки. Подходы:
Создаем общедоступную очередь, например, на Beanstalk, RabbitMQ или Redis или еще на чем-нибудь. Создаем PHP скрипт, который будем запускать из консоли несколько раз, создавая нужное количество процессов. Это решение наиболее универсальное.
Плюсы. Хорошая масштабируемость на несколько серверов, отказоустойчивость.
Минусы. Может быть неудобно или непрозрачно с точки зрения архитектуры. Если в обработке данных несколько “узких горлышек”, то возможно, понадобится предусмотреть несколько очередей.
Создавать потоки через Curl, для такого решения есть даже проект на гитхабе.
Плюсы. Мне неизвестны.
Минусы. Ненадежно.
Использовать popen().
Плюсы. Просто с первого взгляда.
Минусы. Сложно организовать равномерную загрузку ядер. Трудности в создании общей очереди.
Написать собственное расширение для PHP и пользоваться им.
Плюсы. Можно сделать полный фен шуй.
Минусы. Затратно.
Воспользоваться расширением PCNTL. Насколько это удачное решение, возможно, кто-то расскажет в комментариях.
Воспользоваться готовым расширением pthreads.
Плюсы. Надежность. Можно прятать многопоточное поведение внутри модуля, не выносить на уровень архитектуры. Простота в создании общей очереди.
Минусы. Нельзя масштабировать на несколько серверов.
Автор расширения пишет, что именно многопоточность.
Да, и если этот protected метод понадобится переопределить, то будут новые проблемы.
Да, либо так, суть одна
На мой взгляд
$isClientPropsOriginalхорошо смотрелась бы статическим свойством вAbstractEntity. В смысле расходования кофе эффективнее было бы.Предполагаю, что не int из-за того, что там хранят дату в виде целого числа наподобие 20160523222415 (ГГГГММДДччммсс). Но почему тогда не timestamp — хз. Возможно наткнулись на то, что индекс по timestamp в огромных таблицах не всегда эффективно работает в MySQL.
Тогда Go и вовсе Google-oriented
final наследовать нельзя.
Это валюта, в которой хранится сумма. Конструктора просто не хватает в примере. Что-то типа такого должно быть
Это принятое обозначение, чтобы сослаться на метод класса, не важно статический он или нет, вот например, тут так делают. Или я совсем туплю под вечер? :)
Суть-то понятна, но код этого метода — 1 строка, не обязательно на ней было экономить
И
Money::val(). Он чем-то отличается отMoney::getAmount()?На мой взгляд для полноты примера было бы полезно описать код
Money::USD().Да, можно было. Там по горизонтали секунды, вертикальное деление — это 10 секунд. По вертикали % загрузки.
Был включен только для PHP без ZTS
Основные сравнения тут без XDebug. С XDebug только 2 довольно синтетических теста для оценки потерь от использования polyfill.
Не пробовал, но в этом примере должно быть подходящее решение
У каждого подхода свои преимущества и недостатки. Подходы: