Объеденить 2 модели при выводе?

Question

[Nikita]

Есть 2 модели, обе модели отвечают за статьи на сайте, но по структуре в бд они разные. Надо вывести данные с двух моделей на одной странице, при работающей пагинации и сортировки по времени. Пытался объединить 2 массива, но судя по всему это не работает.

Comments

[Adamos]

Ошибка проектирования. Различающиеся данные для статей можно вынести в отдельные таблицы. Разламывать же на две таблицы единую сущность - готовая ручка грабель.

[Nikita]

Adamos, Вот как раз поэтому и возникла эта ситуация, но пока не понимаю как разнести по разным таблицам.

[ThunderCat]

Есть 2 модели, обе модели отвечают за статьи на сайте, но по структуре в бд они разные.

Очевидно что тут либо лажа с 2 моделями где должна быть 1 модель и связь с кастомными таблицами, либо это модель статьи и чего-то другого.

В чем разница между статьями и статьями?

[Adamos]

Nikita, "ситуация" только начала возникать, и ее стоит устранить в зародыше.
По той информации, которую вы дали, ни один телепат вам ничего конкретного не посоветует.

[tukreb]

если 2 модели вообще не имеют ни каких связывающих ключей, но должны быть связаны, то поздравляю, кто-то пропустил базовые знания по проектирование БД :)
Ищите возможность связать 2 таблицы, возможно у кого то должен быть внешний ключ
П.С Возможно они связаны через другие таблицы, эту связь можно использовать.

[Сергей delphinpro]

одна таблица articles
id | title| ...other_common_fileds | created_at
вторая type1_articles
article_id | ...other_different_fields
третья type2_articles
article_id | ...other_different_fields

Дергаем список из articles с сортировкой по времени и пагинацией. Данные из других таблиц через отношения.

[Nikita]

tukreb, Нет, связей между ними быть не должно, по логике, которую мне пояснил один из авторов сайта - это 2 разные сущности, их просто нужно выводить на одной странице.

Adamos, Она возникла давно, просто мне об этом сказали только вчера. Вероятно баг заметили вот только-только.

ThunderCat,

Структура таблиц

Вот так они выглядят, разница не особо видна, не понимаю зачем надо было разделять. Первые статьи выглядят как обычно, а вторые относятся к консультантам и услугам. Объяснение, скорее всего, не очень понятно, извините)

[Nikita]

Сергей delphinpro, Вот я думал о подобном решении, но как это вкрутить в ларавел, пока не придумал.

[Adamos]

Nikita, это не структура таблиц, это тупой скриншот из РМА.
Структура таблиц выдается по запросу SHOW CREATE TABLE, и она - текстовая.

[Nikita]

Adamos,

spoiler

CREATE TABLE `articles` (
 `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
 `title` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
 `slug` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
 `image` longtext COLLATE utf8mb4_unicode_ci DEFAULT NULL,
 `question_id` bigint(20) unsigned DEFAULT NULL,
 `customer_id` bigint(20) unsigned DEFAULT NULL,
 `preview` text COLLATE utf8mb4_unicode_ci DEFAULT NULL,
 `content` longtext COLLATE utf8mb4_unicode_ci NOT NULL,
 `meta_title` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
 `meta_description` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
 `meta_keywords` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
 `active` tinyint(1) NOT NULL DEFAULT 1,
 `created_at` timestamp NULL DEFAULT NULL,
 `updated_at` timestamp NULL DEFAULT NULL,
 PRIMARY KEY (`id`),
 KEY `articles_question_id_foreign` (`question_id`),
 KEY `articles_customer_id_foreign` (`customer_id`),
 FULLTEXT KEY `search` (`title`,`content`,`slug`),
 CONSTRAINT `articles_customer_id_foreign` FOREIGN KEY (`customer_id`) REFERENCES `customers` (`id`) ON DELETE SET NULL,
 CONSTRAINT `articles_question_id_foreign` FOREIGN KEY (`question_id`) REFERENCES `questions` (`id`) ON DELETE SET NULL
) ENGINE=InnoDB AUTO_INCREMENT=105 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

CREATE TABLE `consultant_articles` (
 `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
 `text_uid` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
 `consultant_id` bigint(20) unsigned NOT NULL,
 `title` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
 `parent_category_id` int(11) DEFAULT NULL,
 `category_id` int(11) DEFAULT NULL,
 `service_id` int(11) DEFAULT NULL,
 `content` longtext COLLATE utf8mb4_unicode_ci NOT NULL,
 `seo_details` longtext COLLATE utf8mb4_unicode_ci NOT NULL,
 `image` longtext COLLATE utf8mb4_unicode_ci DEFAULT NULL,
 `status` int(11) NOT NULL DEFAULT 0,
 `created_at` timestamp NULL DEFAULT NULL,
 `updated_at` timestamp NULL DEFAULT NULL,
 PRIMARY KEY (`id`),
 KEY `consultant_articles_consultant_id_foreign` (`consultant_id`),
 FULLTEXT KEY `search` (`title`,`content`),
 CONSTRAINT `consultant_articles_consultant_id_foreign` FOREIGN KEY (`consultant_id`) REFERENCES `consultants` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=12 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

[Сергей delphinpro]

Nikita, вам их в едином списке нужно выводить?

[Nikita]

Сергей delphinpro, Да, с пагинацией и сортировкой по дате

[Adamos]

Nikita, без четкого понимания места этого добра на сайте я бы не рискнул давать какие бы то ни было советы.
Совет все переделать по-человечески, похоже, неприменим.
А вот косметические изменения требуют понимания работы с данными. Например, доступа к этим материалам и поиска по ним.
Возможно, вопрос можно решить добавлением одного поля
`consultant_article_id` bigint(20) unsigned NULL
в первую таблицу, миграцией, создающей соответствующие записи, и обработчика, добавляющего такую запись при каждом добавлении во вторую таблицу.
А может, это создаст больше проблем, чем решит...

[ThunderCat]

Nikita, по таблицам - очевидно что 80% полей в таблицах являются кривыми попытками хардкодинга, напрямую нарушающими 3 нормальую форму. Молчу что такие поля как image, category_id, question_id скорее всего могут быть не 1 ко многим, а многие ко многим, и вообще должны лежать в пивот таблицах к соответствующим сущностям... То же касается принадлежности статей владельцу, их желательно выносить в пивот. Ну или, как минимум не отделять консультантов от кастомеров, так как это 1 класс - пользователи, разделенный через ацл или рбак.

В остальном, как я это вижу - айди, текст, хеадер, слаг, тип и креэйт-апдейт для всех общие, остальное в отдельные сущности вынести.

[Nikita]

ThunderCat, Понял, спасибо. Буду дальше думу думать. А вот по этому поводу

так как это 1 класс - пользователи, разделенный через ацл или рбак.

В данном случае этого нет, на сайте 3 таблицы, юзеры, кастомеры и консультанты)
p.s. еще и для админов отдельная есть, толкьо сейчас увидел

[ThunderCat]

Nikita,

В данном случае этого нет, на сайте 3 таблицы, юзеры, кастомеры и консультанты)

Видимо они с разных уголков галактики, так как не имеют общих признаков, таких как имя/логин, пароль и например гендер, а область их ответственности вшита в генетический код и не может быть выделена в роли, перечисленные в отдельной таблице... Ну да, так часто бывает...

[ThunderCat]

Adamos,

это не структура таблиц, это тупой скриншот из РМА.

и даже его достаточно чтобы сказать что там все криво. Для наколеночной поделки пойдет, но как только возникают вот такие тривиальные задачи, все какахи всплывают со дна...

[Adamos]

ThunderCat, но не исключено, что оно в таком состоянии успешно работает лет десять. И те статьи давно проиндексированы и выносят сайт в топ по своей тематике. Переделаешь по-человечески - слетят ссылки... Благие намерения - дело непростое ;)

[Nikita]

ThunderCat, Это самая малая часть, там есть моменты и похуже. Каждый раз, когда вижу, удивляюсь, как оно работает.

[ThunderCat]

Adamos,

Переделаешь по-человечески - слетят ссылки

так а куда они денутся то? Слаг останется, структура выдачи не меняется, то что это будет работать через другой механизм на сервере на выдачу никак повлиять не должно. На выходе будет абсолютно тот же хтмл что и был, если кто-то в код шаблона не залезет ) Данные просто будут разложены более структурированно, но никуда не денутся...

[Nikita]

Adamos, Статьи на этом сайте - носят чисто информативный характер. Там основной функционал, аля тостер. Только за деньгу. Задаешь вопрос, тебя за деньги консультируют юристы. И да, проекту года 3 точно

[Adamos]

Nikita, по "чисто информативным" статьям в основном и приходят новые посетители из поисковиков. Или, если поисковик видел эту статью по адресу с похеренным в процессе революции айдишником - получают 404 и не приходят.

Answer 1

[Константин Цветков]

CREATE VIEW common AS
  SELECT CONCAT( 'A', id ) AS common_id, created_at, updated_at FROM articles
  UNION
  SELECT CONCAT( 'C', id ) AS common_id, created_at, updated_at FROM consultant_articles

Answer 2

[ThunderCat]

Короче, есть два стула варианта:
1) Хороший, но долгий и муторный - рефакторинг. Переделать таблицы, разнести данные, навести порядок и красоту. Скорее всего это не ваш вариант, ну или придется сильно бодаться с владельцем.
2) Вынести в отдельную таблицу денормализованные данные, то есть айди, материал_айди, материал_тайп, дата. И после выборки уже извращаться на основе выборки из нее с материалами из 2 других таблиц. Если честно - хрень полная, но работать будет. Естественно, при добавлении новых сущностей надо будет еще туда добавлять записи.

Comments

[Adamos]

3) Сделать полностью новую версию сайта, с нормальным хранением и обработкой данных. Не тратя уйму сил на попытки совместить "исторически слежавшееся" с нормальной архитектурой. За счет этого может оказаться даже быстрее рефакторинга.

[Nikita]

Adamos, Лично я бы так и поступил, но боюсь этот вариант вряд ли подойдет заказчику.

"работает - не трогай"

[Adamos]

Nikita, разумеется. Если заказчик хочет от вас только и исключительно поставленной задачи, ее стоит решать минимальным вмешательством, потому что любое другое чревато доминошками.
Вплоть до нулевого изменения таблиц и выборки-разбивки всего прямо в скрипте. При сотне статей за три года бутылочным горлышком это все равно, скорее всего, не станет.

[ThunderCat]

Adamos, тот же рефакторинг, только в профиль. Данные все равно придется перераскладывать, в этом собсно и вся суть работы.

Answer 3

[jazzus]

Конечно, только одна таблица. Для статей articles, для юзеров users, для ролей roles. Такое говнопроектирование оставлять нельзя. А заказчику объяснить, что без исправлений все последующие костыли и время-цена доработок будут по нарастающей.