Adamos

Если хотите идеал, то он должен соответствовать следующим пунктам:

1. Сериализация/десериализация - это дорогостоящее мероприятие, поэтому оно должно делаться только в двух местах: прямо на входе и прямо на выходе. Вход - это ваш контроллер, Выход - это другой сервис, куда вы передаёте данные, или база данных (тут тоже происходит сериализация, либо явно, либо в ORM). Во всех остальных слоях инфообмен должен совершаться уже при помощи объектов PHP либо нативных типов. Это экономит ресурсы. При передаче между слоями приложения объектов вместо значений либо ассоциативных массивов вы сразу будете видеть очепятки, IDE вам прекрасно поможет при помощи автодополнения, объекты могут иметь какие-то полезные методы.

2. Очень желательно в каждом из слоёв иметь собственный класс, отвечающий за данные. Например, нам в слой API приходит JSON-чик с новым пользователем.
- Сериализуем JSON в DTO UserInAPI, сразу валидируем всё то, что мы можем валидировать без слоя бизнес-логики, и либо отдаём клиенту ошибку, либо передаём сам объект UserInAPI в следующий слой: слой бизнес-логики
- В слое бизнес логики, получаем DTO UserInAPI на входе, преобразуем его в свой бизнес-объект UserInBusiness, валидируем его уже с точки зрения бизнеса, и либо возвращаем ошибку в слой API, либо совершаем над ним действия, и передаём объект класса UserInBusiness в слой работы с базой
- В слое работы с базой данных получаем на входе объект UserInBusiness, преобразуем его уже в сущность базы данных UserInDB, валидируем всё на предмет корректности данных для базы, и либо возвращаем ошибку в бизнес, либо сохраняем сущность класса UserInDB в базу.

Зачем такие сложности, вы спросите? А просто обратите внимание на то, что скорость изменения кода в разных слоях разная.
- API вообще должен меняться раз в сто лет, чтобы не злить клиентов. Поэтому DTO класс UserInAPI будет стабильным и редко будет меняться.
- Бизнес-логика меняется очень часто. У класса UserInBusiness постоянно будут добавляться поля и методы, тут жизнь будет кипеть.
- Слой базы данных будет меняться реже, чем слой бизнеса, но чаще, чем слой API, потому что нам нужны будут новые поля в базе, новые таблицы и связанные таблицы.
- И если мы один тип сущности протащим во все слои, то эта сущность обрастёт таким количеством различной хрени, что нам плохо станет, когда будем на неё смотреть. Либо она обрастёт кучей декораторов в каждом из слоёв. Поэтому лучше всё разделить.

3. Теперь внимание, казалось бы, что мы слишком сильно связываем наши слои, и нижестоящие слои знают что-то о вышестоящих, а это неправильно. Ведь мы передаём объект UserInAPI в слой бизнеса, т.е. слой бизнеса должен уметь работать с этим объектом. И так же слой базы должен уметь работать с объектом бизнеса UserInBusiness. Как же быть? А очень просто. На входе слоёв использовать интерфейсы. Т.е. в слое бизнеса мы будем принимать не сам класс UserInAPI, а объект, имплементирующий интерфейс UserIncoming, который объявим в бизнес слое, и заставим слой API сделать так, чтобы его класс UserInAPI имплементировал этот интерфейс. Таким образом слой бизнеса ничего не будет знать о слое API, а будет ждать на входе данные по контракту, описанному в интерфейсе. Бизнесу плевать на конкретную реализацию, ему нужны только методы getUsername, getEmail из интерфейса. А какой класс ему их предоставит - пофигу. Таким образом мы практически полностью разделяем слои и в два счёта сможем поменять слой API, где у нас HTTP контроллеры, на слой RabbitMQ, SOAP, Grpc и т.д.

ubuntu

https://designpatternsphp.readthedocs.io/en/latest...

Проблема заключается в том, что в вашей функции условие WHERE \orderid` = 871жестко зафиксировано, и оно всегда будет брать строку с этимorderid, игнорируя переданное значение orderid` в параметр функции.

Чтобы учитывать переданное значение в параметр функции, необходимо использовать сам параметр orderid вместо фиксированного значения. Вот исправленный код функции:

DROP FUNCTION IF EXISTS YourFunction;
DELIMITER $$
CREATE FUNCTION YourFunction (qty INT, orderid INT) RETURNS TEXT

BEGIN
DECLARE text_t TEXT;
SELECT `sum` INTO text_t FROM t_order_price_type WHERE `orderid` = orderid LIMIT 1;
RETURN text_t;
END$$

DELIMITER ;

Однако, в данном виде WHERE \orderid` = orderid` не сработает так, как вы ожидаете, потому что MySQL может спутать поле таблицы с параметром функции. Чтобы избежать этой путаницы, лучше использовать псевдонимы или уникальные имена для параметров. Например:

DROP FUNCTION IF EXISTS YourFunction;
DELIMITER $$
CREATE FUNCTION YourFunction (p_qty INT, p_orderid INT) RETURNS TEXT

BEGIN
DECLARE text_t TEXT;
SELECT `sum` INTO text_t FROM t_order_price_type WHERE `orderid` = p_orderid LIMIT 1;
RETURN text_t;
END$$

DELIMITER ;

Здесь параметр функции называется p_orderid, что предотвращает конфликт имен между полем таблицы и параметром функции.

Вдруг будет слишком долго?

Не будет. Забудьте вообще на данном этапе своего обучения про существование такого понятия как "скорость", пока не столкнётесь с тормозами в реальности.

Хочется redis

Его сложнее администрировать, чем sqlite. Но если хотите - развлекайтесь.

А не лучше ли узнать в конкретной типографии, в которой собираетесь заказывать этикетки?

Плохо, даже для разработки. Например недоступен github.
Какие еще есть подводные камни IPv6 Only на сервере разработки?

Очень многие на Ваш сайт просто не попадут. как уже указали - потому что поддержка ipv6 пока сильно ограничена.
Вопрос можно решить через cdn, например cloudflare, которые будет перенаправлять ipv4 на ваш ipv6.

А вот сам вопрос заинтересовал - что на современных сервере и сайте может сломаться без IPv4?

У большинства посетителей всё ещё тупо нет ipv6 => они не смогут получить доступ к сайту.
Например, в моём городе всего у одного провайдера есть ipv6.
Много инструкций всё ещё на уровне винды рекомендуют выключать ipv6