1. Вопрос был про то, что нужно делать в случаях, когда объект получает в конструктор входные данные для инициализации, но возникают случаи, когда объект не может быть инициализировать (с которым нельзя дальше работать), из-за разных причинТут как раз сильно зависит от причин. И в конкретно этом случае ваш подход хреновый. Не может быть хорошим решением выборка в 200 запросов циклом. Инфа 146%.
Представьте себе - есть правило, по которому данные ссылочного типа не удаляются. Да, оно чисто архитектурное и имеет косвенную связь с 3 нормальной формой. Есть даже специальный конструкт - внешний ключ, который определяет поведение при удалении связанных данных, и по умолчанию он прерывает удаление.На самом деле удалять ничего не надо было, просто достаточно пометить ненужные записи как неактивные.
Вы "Куратор тега PHP" и пишете такие вещи.
А кто сказал, что нужно деактивировать ? Это какое-то правило проектирование БД?
Мы работаем с CMS, в которой уже вся архитектура такая, какая есть.Ну, для начала надо бы упомянуть что вы работаете с CMS, это бы многое прояснило, хотя все еще не вижу причин не изменять штатные объекты или наследоваться от них.
любая (адекватная) CMS может обновляться, и в любой момент может меняться структура БД.Нет, или адекватная, или меняться структура. Тут без вопросов, обратная совместимость изменений - базовый аспект для любого адекватного приложения. Только смена парадигмы и какой-то жесткий факап в базовой структуре может сподвигнуть на такие меры как изменение архитектуры вплоть до несовместимости интерфейсов.
Советчики, которые рекомендуют работать напрямую c sql, и не использовать орм, чтобы оптимизировать выгрузку в 200к записей - это вообще... диванные эксперты.Ну, на промышленных системах так часто делают, ибо отчеты реально быстрее сформировать 1 сложным запросом, нежели 10 простых + логика на бэкенде. Но в основном все же орм может все это своими силами. Просто нужно хоть чуточку в нее уметь.
1. 2. Остатки считаются партионно циклом по каждой номенклатуре. Способ проще пока не удалось найти. Т.е. если в магазине 100 видов товаров, то будет 100 запров к таблице продаж и 100 к таблице закупок.В принципе, на этом можно закрывать вопрос.
не должен и в "базовом стандарте"в3ц - не стандарт, а рекомендация, а строковые параметры отделяются кавычками по стандарту (большинства) языков (и языков разметки в том числе). Другое дело что возникает чехарда с кавычками, когда сам параметр уже в кавычках (по сути уже строка), как в случае инлайнового стиля, и приходится либо не писать кавычки, либо использовать одинарные и двойные для разделения. В том числе для предотвращения разночтений между заковыченным текстом и продолжением строки. А в случае локальных виндовых адресов или нестандартных путей без этого вообще работать не будет. То есть все это расписывать, упоминать что стили в свое время не имели обязательного отделения кавычками в инлайновом описании в половине браузеров и тд пожалуй длинновато. Короче написать "нужны кавычки".
Поэтому ваше утверждение "урл должен быть в кавычках" не должно быть категоричным.Тут да, высказывание звучит как утверждение, хотя на самом деле рекомендация. И кстати в формате представленным ТС вполне может не работать без кавычек, так как русские символы, пробелы и разный регистр в урл без кавычек вообще не понятно как будет работать в такой солянке.
тут же задана высотамаксимальная высота, а минимальная или базовая не задана, по умолчанию она нулевая.
background - это сокращенное свойство, которое включает в себя и background-image.ага, а теперь пройдите по ссылке и посмотрите что же рекомендует в данном случае мдн. Вообще - да, кавычки опциональны, но в базовом стандарте они были, и в доках везде по прежнему они есть. Лучше поставить, так и семантически отделяется строковое значение, и с базовым определением совпадает.
//Убираем Notice, а все остальные ошибки выводимТак делать не нужно, выводить нужно ВСЕ о чем предупреждает интерпретатор, выключить ошибки можно только на продакшне, когда проект завершен и оттестирован.