Как работает парсер (пример внутри)?

Кривой частный случай

но ведь данные о лекарствах и аптеках где-то хранятся, разве не в базе данных?

AlbertS001, в моем случае они нигде не хранились.
Есть сайт крупной оптовой конторы со своим поиском. Свои базы они не дают, чтобы можно было ее залить в свои товары и обновлять, например, каждый день по крону.
Поэтому наш сайт запрашивает с их сайта, например, товар с артикулом "АБВГД" (то что наш посетитель ввел в поиск).
Потом разбираем страницу с тем, что нашлось на сайте оптовика и показываем нашему посетителю.
Никакие базы данных не используем.
А вот если наш посетитель добавил что то в корзину, тут удобнее всего использовать движок магазина и пользоваться его возможностями, соотв с базой данной и т.д.

Александр Суханов, А если делать подобное именно с парсером чтоб он заносил всё в базу данных, то какие таблицы были бы нужны?

AlbertS001,

А если делать подобное именно с парсером чтоб он заносил всё в базу данных, то какие таблицы были бы нужны?

Такие, какие будут после проектирования и построения модели.

AlbertS001, Вы хотите все это сделать без использования движка?
Если так, то определять все нужные поля для товаров и делать таблицу, если нужно как то отделять по аптекам, то еще таблицу для аптек и т.д.

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

Только это не нужно. Зачем вам заносить эту информацию себе?
Это имеет смысл только если занести себе всю базу с товарами. Тогда ваш поиск будет работать самостоятельно, что будет намного быстрее и не нужно будет никаких парсеров и возможных багов с ним.

Я вбил в вашем поиске "Ринонорм", вы это спарсили, занесли себе все данные и мне показали.
Итого в ваших таблицах появилось 500 ненужных товаров.
Завтра другой человек запросит "Ринонорм", вы ему что хотите показать? То что показывали вчера и не использовать парсер (что будет быстрее) ? если так, то где гарантии, что цены не поменялись или другая инфомация. А если опять применять парсер, то зачем эти данные хранить у себя?

Сам такой парсер по чужому поиску - далеко не лучший вариант, а делать записи в свою базу еще более...

Вы поглядите, может нужный вам сайт (откуда вы хотите брать информацию) предоставляет доступы к своей базе данных,например, по api или просто дает всю ее скачать.

То есть он заносит информацию о лекарствах в отдельную таблицу, об аптеках тоже в отдельную, о производителях в отдельную. А потом из этих таблиц собирает всю эту информацию вв агрегированную таблицу и заносит каждому лекарству цену?

AlbertS001, это детали реализации. Зависит от конкретной задачи и вариантов использования.

Yan-s, ну например есть таблицы: аптеки, справочник препратов, препараты и производители. В аптеки парсер заносит аптеки, в справочник препаратов названия и другую инфу о препаратах, в прозводители- инфу о производителях, а таблица Препараты - агрегированная и в неё берутся данные из других таблиц( спр препаратов, аптеки, производители) и заносится цена. Парсер может так делать?

AlbertS001, а что ему помешает?

Если вас интересует хранение данных то почитайте про реляционные субд и нормальные формы бд.

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

Это собственно и основная суть реляционных СУБД к которым относится, например, mysql, sqlite, postgresql и дофига еще каких.