smuravskii, у redbean отвратительная репутация. Какой-то жулик форсит эту либу в своих видео, не объясняя вообще ничего, и в итоге все форумы завалены вопросами от людей которые буквально не понимают ни слова в том коде, который пишут.
Так что лучше уж пусть учится по-старинце - сначала mysql, потом РНР.
А PDO ничем не лучше mysqi в плане защиты от инъекций, так что это "хотя бы" не в тему. Тем более что твой код не решает проблему автора вопроса
Извини приятель, какой вопрос ты задал, на такой я и написал ответ. Про json_encode.
Зайдет в этот вопрос человек из гугла, привлеченный заголовком, а тут какие-то туманные рассуждения про определение кодировок, никакого отношения к json не имеющие.
Но вообще задача автоматического определения кодировки в целом не решается. Так что просто отбрасывай такие значения
процессор у тебя умрет на твоем колупании с запятыми. Потому что чтобы в твоем варианте заменить одно число, надо будет прочитать тесячу, заменить, а потом записать обратно тысячу.
А в нормальном варанте всегда будет читаться только 1 число, сколько бы подписок всего не было.
Поверь, базы данных проектировали не полные идиоты. Ну уж во всякоим случае люди не тупее тебя. И немного понимающие в загрузке процессоров.
Да. И тут на первый план выхолдит организация ORM и становится очевидной превосходство стратегии Data Mapper, когда слой работы с БД полностью отвязывается от объекта бизнес-логики.
Так что да, я бы написал в маппере отдельный метод, который делает джойн и заполняет из результатов коллекцию, создавая по ходу все нужные объекты.
И когда появится свойство категория, надо будет дописать код, который подгружает категории тоже. Вообще, Доктрина пытается автоматизировать этот процесс тоже, но там можно очень быстро намотаться на шпиндель и оторвать себе руку.
Некоторые идут ещё дальше, и не пишут методов, которые возвращают универсальную коллекию, а пишут отдельный метод для каждого случая, когда требуются данные товара - для каталога один, для корзины - второй и т д.
И это мы сейчас говорим о read-моделях, и даже не трогали тему write models - то есть сохранения измененного объекта - со всеми гроздьями смежных объектов(!) - в БД!