«Hello, (real) world!» на php в 2017 году

Ну например «хотите чтобы ваш круто интернет-магазин вообще поисковиками индексировался»

А он индексируется только при изоморфном рендеринге? :)
Или других способов отдавать выдачу не за 5 секунд нет?

Продать-то можно что угодно — вон участки на Луне вполне себе продают…
Но реальный плюс какой?

«Hello, (real) world!» на php в 2017 году

Вы нам лучше объясните какой плюс заказчику от изоморфного рендеринга :)

Ненаучная революция: как недостаток реальных исследований губит технологические проекты

На самом деле и сейчас уже проблема :) для большинства айтишников так точно.

И естественно запросы для жизни выросли.
Собственно в связи с этим и возник вопрос о пассаже.
Автор его дурак? или что?

MySQL и MongoDB — когда и что лучше использовать

Сами списки для некоторых вещей дороже. И менее гибкие.

И большой проблемой становится когда нам надо иметь более 1-2 порядков элементов в списках, да еще с фильтрацией

MySQL и MongoDB — когда и что лучше использовать

Если бы технология была выгодна только для бизнеса, бизнес бы о ней никогда не узнал (кто б ему рассказал)

какая наивность…

MySQL и MongoDB — когда и что лучше использовать

Если кто и троллил, то код, с которым сталкиваюсь ежедневно, в котором связи (причем с контролем ссылочной целостности) лепятся просто по умолчанию.

А это скорее от тяги попробовать все новое. И раз есть — надо применять…

Я в одном месте встретил каскадное удаление первичных документов после удаления акции по которой они могли создаваться.
В результате посетитель приходил, ему приходила смс, а вот заявки о нем в БД не было от слова вовсе…

MySQL и MongoDB — когда и что лучше использовать

Именно, что тупо копирую. Моя задача как разработчика автоматизировать имеющиеся бизнес-процессы, зачастую заданные даже не бизнесом, а государством.

Фиговые у вас аналитики, раз ставят именно такие задачи.

Например, тот же НБУ еще в 1999 году издавал соответствующие постановления об электронном документообороте. И там была формализация результатов, а не процесса.

2.1.1. Вимоги до первинних облікових документів
Підставою для бухгалтерського обліку операцій банку є
первинні документи, які фіксують факти здійснення цих операцій.
Первинні документи повинні бути складені під час здійснення
операції, а якщо це неможливо — безпосередньо після її закінчення
та можуть складатися у паперовій формі та/або у вигляді
електронних записів (у формі, яка доступна для читання та виключає
можливість внесення будь-яких змін). У разі складання їх у вигляді
електронних записів при потребі повинно бути забезпечене отримання
інформації на паперовому носії.
Первинні документи як у паперовій формі, так і у вигляді
електронних записів (непаперовій формі) повинні мати такі
обов'язкові реквізити:
— назву документа (форми);
— дату складання документа; { Абзац п'ятий підпункту 2.1.1
пункту 2.1 із змінами, внесеними згідно з Постановою Національного
банку N 283 ( z0675-01 ) від 18.07.2001 }
— назву підприємства (банку), від імені якого складений
документ;
— місце складання документа;
— назву отримувача коштів;
— зміст операції (підстави для її здійснення) та одиницю її
виміру; { Абзац дев'ятий підпункту 2.1.1 пункту 2.1 із змінами,
внесеними згідно з Постановою Національного банку N 203
( z0926-12 ) від 23.05.2012 }

и т.д. и т.п.

MySQL и MongoDB — когда и что лучше использовать

а потом проследить, что была создана адекватная струтура и сгенерированы оптимальные запросы.

Это как бы не сложнее чем знать все диалекты.
А уж степень глупости потерянного времени прямо таки безразмерная. Ибо сначала создаем себе трудности, а потом героически их преодолеваем.

ORM снижает требования к качеству среднестатистического разработчика — это его основной плюс и выгода для бизнеса.

MySQL и MongoDB — когда и что лучше использовать

Эм, у вас какой-то свой взгляд на реляционную модель.
Базой ее является то, что данные представляются в формате связей.

Вас кто-то знатно потроллил на тему нормальных моделей.

Так вот — нормальные формы как и любые другие абстракции следует применять там, где это уместно. Непосрественно же реляционная модель на это не накладывает ограничений.

Правильное моделирование сущностей типа заказа заключается

Неа, не заключается.

Ибо зависит от анализа предметной области. Вы же не тупо 1 в 1 копируете бизнеспроцессы, которые родились еще во времена бумажного документооборота и никакой другой формы кроме «копирования значимых данных» не предусматривали.

«Hello, (real) world!» на php в 2017 году

Вот вариант когда отдельные классы на каждый тип действия
И естественно фабрики для них примерно так выглядят

            App\Action\User\Register::class => function (ContainerInterface $container) {
                return new \App\Action\User\Register(
                    $container->get(RouterInterface::class),
                    $container->get(TemplateInterface::class),
                    // прочие зависимости
                );
            },
            App\Action\User\Login::class => function (ContainerInterface $container) {
                return new \App\Action\User\Login(
                    $container->get(RouterInterface::class),
                    $container->get(TemplateInterface::class),
                    // прочие зависимости
                );
            },

MySQL и MongoDB — когда и что лучше использовать

Реляционные же «заставляют» нас делать либо каскадное удаление, либо вводить какой-то атрибут «уволен»

Считаете неправильным хранить значимую историю изменений?

MySQL и MongoDB — когда и что лучше использовать

Справедливости ради, даже при 1000-2000 входящих ежедневно (а это достаточно крупная компания) для современного сервера это не нагрузка

MySQL и MongoDB — когда и что лучше использовать

Внезапно, да. По умолчанию в них бы внесли значение user_fullname

Ну таки в ловушку попались.

Ведь для случаев, когда критична смена фамилии вам же нужно знать не только фамилию подписавшего, но и однозначно идентифицировать его по этой фамилии.

А из вашего рассказа получается что после смены фамилии документы теряют связь с пользователем, но продолжают хранить информацию о его бывшей фамилии…

То есть в документе зафиксирован Вася Пупкин, а вот самих Пупкиных в вашей БД при этом может не быть вовсе теперь.

Так что, как вы справедливо указали, проблема именно в

не вникая ни то, что в бизнес-процессы

И schema-less в данном случае просто создают другой тип ошибки неконсистентности данных

«Hello, (real) world!» на php в 2017 году

Я вам открою Америку.

http://socketo.me

Пользуйтесь.

Ненаучная революция: как недостаток реальных исследований губит технологические проекты

Вооруженный информацией, человек как никогда раньше независим и самодостаточен.

Простите что?

Независим и самодостаточен в отношении чего?

Лет эдак с десяток тысяч назад каждый, подчеркиваю, каждый мог произвести самостоятельно все необходимое для жизни.

Кто из современных людей способен создать хотя бы треть нужного ему для жизни самостоятельно — вне общества?

MySQL и MongoDB — когда и что лучше использовать

Но не учли, что людям, особенно девушкам, свойственно иногда менять ФИО, а на печатных формах ФИО пользователя должно быть на момент, грубо говоря, создания документа.

К реляционным базам это имеет никакое отношение.

В вашем конкретном случае документы должны были иметь два поля user_id, user_fullname, например.

Это если нигде более смена фамилии не является критичной.
В противном случае вам придётся вынести список фамилий и имён пользователя выносить в отдельную сущность и хранить в отдельной таблице user_id, firstname, lastname, date_create…

Но интересен другой вопрос.
MongoDB и прочие schema-less решения каким образом внезапно спасли бы вас в описанном вами случае?

«Hello, (real) world!» на php в 2017 году

Тем что при слабой связности вы будете иметь раздутый конструктор для всех зависимостей. При том что в самих action все одновременно они не требуются.

Вот для случаев описанных ниже

один класс с 5-ю экшенами связанными по смыслу,

Можно.

Я только не совсем понимаю почему они связаны между собой, а зависимости при этом у всех разные…
Из чего и возникает потребность получать зависимости непосредственно при вызове action

«Hello, (real) world!» на php в 2017 году

Зачем?

Если у меня приложение поддерживает несколько форматов рендеринга, то я это свяжу на этапе роутинга например.

Или в самом контроллере анализируя пришедший из роутинга параметр формата буду подключать необходимые View.
Эдакий Context switch.

Суть в том, что никому другому знать о том поддерживает ли контроллер разные форматы не нужно.

Вот ACL это неплохой пример post-routing события.
Информации для принятия решения к этому времени уже достаточно

«Hello, (real) world!» на php в 2017 году

В моем понимании разные форматы это рендеринг в разные View

Соответственно постпроцессинг запросов в middleware у вас потом ответ куда отдаёт?

«Hello, (real) world!» на php в 2017 году

Чем он формально будет отличаться от контроллера?

Вы контроллер можете инстанцировать через фабрики. Зачем там middleware?