Сергей, ну так если их нет в таблице а, то условие на таблицу а не нужно? Это нижняя часть ответа. Ну, или нарисуй данные в а, данные в б и результат. Типа тест кейс. Начальное заполнение можно сделать на sqlfiddle, например
а что должно попасть в результат, если в таблице А есть соответствующая запись, но нет записи в Б? что должно попасть в результат, если В А есть запись, соответсвующая Б, но у неё не выполняется условие? Что если в А вообще нет записи?
Телепат говорит, что нужен не full join, а left join и всё
SELECT * FROM A
LEFT JOIN B ON A.key = B.key
WHERE A.date = '33'
Алексей Сундуков, на план исполнения влияют не только индексы на ключи соединения, но и прочие условия. Да и при большом количестве джоинов тоже может быть грустно. При простом запросе без дополнительных условий и трех таблицах скорее всего один запрос будет чуть быстрее. При появлении условий, особенно на правые таблицы - не факт. Да еще и при "каскадном" джоине, когда а->b->c связь, а не a-> + a->c. В таком случае уже нужно смотреть замеры на реальных данных.
kamilqiyasov, ну тогда только QueryBuilder. Но на самом деле не так много. И часто большое количество джоинов обманывает оптимизатор и он выбирает неоптимальный план выполнения и один большой запрос дольше нескольких маленьких. Особенно если они в одном пакете и не теряется время на межпроцессное (и даже межсерверное) взаимодействие несколько раз на каждый запрос.
Denioo, подключайте компонент, в котором в хуке маунтед этот код после того, как все загрузится. До того, как все загрузится, показывайте другой компонент или ничего. C помощью v-if или <component :is="..."/>
А иначе зачем вам стор, если компонент один?
topuserman, Не надо передавать id в конструктор, надо туда передавать уже полученную сущность (строку БД, еще что). А то как тестировать будете? А вообще не надо изобретать ORM, пользуйтесь готовыми. Ну или если очень хочется, почитайте про фабричные методы, инверсию зависимостей и прочую теорию.
Это офигенное решение. На торг12 можно печатать шк для складской программи, который запкстит процесс сборки именно этой накладной, ну и выведет инфу по ней
MasterCopipaster, это очень странно. и в php artisan route:list тоже такого маршрута нет?
можно php artisan route:clear попробовать, вдруг в кэше маршрут залип.
MagAssist, скорее всего проблема с журналом, вернее с его индексом. можно включить возможность изменения в поддержке, добавить графу журнала, применить изменения (будет реструктуризация одной таблицы, достаточно быстро), потом в меню поддержки сравнить объединить с конфигурацией поставщика с постановкой обратно на замок. будет ещё одна реструктуризация, но тоже быстрая. естественно, перед этим нужно сделать бэкап, если его еще нет.
Есть еще обработка на инфостарте, которая делает что-то похожее, но она не про дубли а про разные данные в журнале и в списке документов, так что может и не помочь: https://infostart.ru/public/197614/
при её использовании бэкап также обязателен.