ВэйДлин: Дата (и время) публикации новости. Опишу на примере. Допустим в базе есть 25 новостей. Пользователь заходит на сайт и ему подгружаются первые 20 новостей. В этот момент времени, все новости в базе имеют время публикации, которое меньше чем текущее. Запоминаем текущее время (логично это делать на клиенте, т.е. в JS).
Пока пользователь пялится на заголовки новостей, кто-то добавляет ещё одну новость. Теперь в базе 26 новостей. Время публикации добавленной новости больше чем то время что мы запомнили на клиенте.
Загружая следующую порцию новостей мы говорим серверу - "дай мне 20 новостей пропустив 20 от начала, но работай только с теми новостями, время публикации которых меньше того что я тебе дам". Тем самым мы из 26 новостей в базе, не смотрим на добавленную, пропускаем первые 20 и получаем последние 5.
Если бы мы обращали внимание и на новую новость, то могла бы возникнуть ситуация, когда эта новость, по нашим же правилам сортировки попадает в первую двадцатку. Тогда, новость которая была под номером 20 при первой загрузке, станет новостью под номером 21 при загрузке второй части данных, и у пользователя в списке новостей будет повтор.
Такой подход не идеальный. Пользователь не увидит новых новостей пока листает вниз. Пользователь может наткнуться на удалённую новость, если долго будет смотреть на список новостей. Но обычно, новости чаще добавляются чем удаляются, и вероятностью того что пользователь нажмёт на ссылку с несуществующей новостью можно пренебречь.
Система полной синхронизации списка у пользователя со списком в БД на новостном сайте будет избыточна. Тут потребуется постоянное постоянное соединение с сервером и полноценное клиентское приложение на JS. Это как забивать гвозди микроскопом.
ВэйДлин: нет. Посмотрите внимательно, я ориентируюсь не на дату какой-то новости из первой выборки, а на дату получения страницы. Пользователю будут отдаваться все новости, которые уже были в базе на момент загрузки страницы.
lxfr: Ну смотри. Есть docker-хост, на нём работает docker-демон.
Когда ты набираешь в консоли команду docker run ... ты на самом деле используешь docker-клиент, который обращается к демону.
Соответственно можно реализовать собственный клиент, который будет посылать какие угодно команды демону, в том числе и на запуск контейнеров.
Для этого достаточно посылать json на соккет доккера.
lxfr: Возможно я и напутал с -i и с -d, но про "docker-php не надо трогать" вы не правы. У человека задача - запустить контейнер из php. Наиболее правильный путь для этого - использовать api доккера.
lxfr: да, там есть -it, это значит, что docker run в интерактивном режиме будет писать в виртуальный tty и не отпустит его пока не отработает. Там ещё есть параметр -d, что как бы противоречит параметру -i.
Не могу сказать что точно должно случиться, т.к. сам такой изврат с -i и -d в одном флаконе не делал, да ещё и неясно что за процесс стартует.
Но полагаясь на слова автора "Когда руками запускаю в консоли - этот код работает", предположу, что происходит конфликт имени контейнера.
Тут либо делать run с удалением контейнера, либо делать run только один раз, а все другие разы только exec.
Тут уже чистая математика. Когда у вас все атрибуты в одной таблице, то во время запроса с условием, СУБД проходит по каждой строке и смотрит чтобы она подходила, получается O(n). Естественно, если разбить эту одну таблицу на m штук, то и обрабатываться будет меньше строк - грубо говоря O(n/m).
Мы думали об этом, когда у нас в таблице атрибутов стало больше 3 млн. записей.
Дальше мыслей дело не пошло, т.к. было решено отказаться от EAV, но не потому что было найдено лучшее решение, а из-за того, что EAV не была нужна вовсе, т.к. не было сущностей с переменным числом атрибутов.
Если говорить о товарах, то использование EAV-подобной системы это классика. При постраничном отображении оверхед не очень большой, а если кешировать, то и вовсе минимальный.
Оперирование таблицами больше подходит для случаев, когда создаются не однотипные сущности с фиксированным количеством атрибутов - как раз как инфоблоки битрикса, которые могут быть чем угодно. Насколько помню как раз у битрикса хайлоад инфоблоки делаются через таблицы.
Ну или можно запариться и сделать конструктор таблиц в админке сайта. Т.е. ты в админке накликиваешь атрибуты в сущность, жмёшь "сохранить" и сервер формирует запрос create table...
Вот тут php.net/manual/ru/language.types.float.php официально заявлено, что php из коробки не умеет поддерживать точность флоата. Т.е. это не столько ошибка сериализации, сколько действительно точное преобразование числа в строку.
Там же сказано, что для точных вычислений надо использовать отдельные расширения =(
IgorRastarov:
Так себе решение. ID нужен в 90% случаев, особенно для такой полноценной сущности как user. Чтобы поле заполнялось автоматические, оно должно быть auto_increment.
Если и можно определить что страница отображается в iframe, то это должен делать код, который работает в браузере. Я не знаю возможно ли это с точки зрения JS API, но предполагаю, что можно изнутри iframe с помощью js взять внешний документ, а точнее даже окно, и получить его адресную строку. Ну а там уже смотреть на домен - хороший он или плохой.
echo $day_orders->cnt;