Николай Романов, не говоря о том что в этой одной базе на все, можно хранить шаблон данных и тогда сайт будет подтаскивать шаблон - в нем подставлять данные и выводить - и вся заливка данных сведется к тому что бы поправить шаблон и данные.
1. Сделать кучу views от таблицы где будут нужные столбики, и сайты будут лезть в свой view.
2. Сделать view от таблицы где будет столбик один, но json и от него плясать.
3. В каком нибудь постргесе вообще можно сделать гадость при помощи create rule и код выполняя select к таблице будет получать только те данные что вы ему даете.
4. Сделать trigger на insert который будет по таблицам для каждого сайта класть свое.
Pupochkin123, ну ровно соблюдать правило тонкие контроллеры / толстые модели-сервисы. Всю ту движуху в контроллере которую вы хотите вызывать из другого контроллера - надо куда нибудь вынести в модель, в сервис - зависит от вашего кода и того что там происходит. И вызывать уже там. И в дальнейшем соблюдать это правило.
Просто завтра к примеру этот же код надо будет вызывать разбирая какую нибудь очередь в раббите и что? Вы тоже там контроллер будете вызывать?
Pupochkin123,
исправил - не разглядел вторую ошибку
З.Ы. то есть судя повсему: вы только что открыли для себя почему "thin controllers, fat models/services" и вместо того что бы начать исправлять это - вы начали расставлять костыли?
runprogr, ну просто если они не участвуют в выборке ну то есть по ним нет условий, то самое простое будет добавить понятие UserRole, все эти поля вынести к чертям в UserData и пихать в поле json. или в текст и в модели поставить $casts = [ 'data' => 'object'] пусть Laravel сам там парится. Тогда у нас будет 1 нормальная сущность - Пользователь. В FormRequest захерачить requiredIf для полей и иже с ними
Akina,
1. Ну то есть если мы сносим данные каждый час, у нас может накопиться несколько больше 10 записей. И что бы они не маячили - в запросе просто используем limit.
2. Возможно обойти наверно - через промежуточную таблицу тоже с триггером.
3. Да перепутал с on duplicate update, с mysql не работал уже лет 5. но принцип то схож
Как по мне, единственная странность - это требование "строго десять". Остальное вполне укладывается в стандартный шаблон.
Мне представляется странной задача ДЕРЖАТЬ в таблице не больше n записей. Мы получаем кучу геммороя с тем что у нас не просто вставка - а вставка с проверкой и возможным удалением. То есть вместо 1 задачи у нас 3. Вопрос зачем, в чем ценность этого для приложения или бизнеса? Что случится если там какое то время будет лежать больше 10 записей? Коллапс?
