Блог

У меня есть база данных, содержащая более 1000 сведений об элементах, и сейчас я разрабатываю систему, которая будет проверять источник API с помощью обычного задания Cron, добавляя новые записи по мере их поступления. Обычно, но не всегда, когда выпускается новый элемент, он будет содержать ограниченную информацию, например; Только изображение и имя, иногда дополнительная информация, такая как описание, может быть изначально скрыта.

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

Например, в базе данных можно прочитать что-то вроде следующего

 <p>Today new items were released!</p>
<?php $item_ids = "545, 546, 547, 548"; ?>
  

А затем на странице будет извлечена последняя известная информация из другой таблицы базы данных для элементов «545, 546, 547, 548»

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

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

 CREATE TABLE `announcements` (
    `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
    `publish_date` DATETIME NOT NULL,
    `content` text,
    PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

CREATE TABLE `items` (
     `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
     `title` VARCHAR(128) NOT NULL,
     `description` text,
     PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

CREATE TABLE `announcement_item_lkp` (
     `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
     `announcement_id` int(11) unsigned NOT NULL,
     `item_id` int(11) unsigned NOT NULL,
     PRIMARY KEY (`id`),
     UNIQUE KEY `announcement_item_lkp_uk1` (`announcement_id`,`item_id`),
     KEY `announcement_item_lkp_fk_1` (`announcement_id`),
     KEY `announcement_item_lkp_fk_2` (`item_id`),
     CONSTRAINT `announcement_item_lkp_fk_1` FOREIGN KEY (`announcement_id`) REFERENCES `announcements` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
     CONSTRAINT `announcement_item_lkp_fk_2` FOREIGN KEY (`item_id`) REFERENCES `items` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
  

С announcement_item_lkp помощью таблицы вы можете связать столько элементов с вашим объявлением, сколько захотите. И поскольку у вас есть каскадные удаления, если элемент получает удаление, его записи поиска также удаляются, поэтому вам не нужно беспокоиться о потерянных ссылках в ваших объявлениях, как если бы вы просто вставляли строку идентификаторов куда-нибудь.

Вы уже используете реляционную базу данных, позвольте ей выполнять свою работу.