Есть вариант решения: Хранить в БД только название вакансии и параметры для поиска, а описание хранить в ZIP архивах.
В целом, хранение названия вакансии отдельно от подробного описания вакансии - правильный подход. И сжимать текстовые данные - тоже правильно. Вот только хранить описания в файлах ZIP не стоит по причинам, описанным
index0h . Правильно хранить данные в СУБД. А сами текстовые данные можно сжимать любыми алгоритмами сжатия перед занесением. Также хочу прояснить, что ZIP - это контейнер файлов, в котором могут использоваться различные алгоритмы сжатия, от Shrunk и Deflate до таких как PPMd.
В InnoDB СУБД MySQL 5.7 сжатие может применяться прозрачно при помощи директивы
COMPRESSION:
CREATE TABLE t1 (c1 INT) COMPRESSION="zlib";
Поскольку вакансии обычно повторяются из месяца в месяц, от одной доски сообщений к другой, то скорее всего имеет место множественное дублирование одних и тех же вакансий. В таком случае можно применить технику оптимизации под названием "дедупликация данных".
Для этого можно вычислять хеш-сумму криптографическими хеш-функциями, такими как SHA-1. Одни и те же описания вакансий будут иметь ту же хеш-сумму, что позволит хранить лишь одну копию описания. В таком случае данные буду разрастаться гораздо медленнее, чем без этой техники.
Связи можно хранить так:
job_vacancies(id, ...) <-> relations(source_id, packed_contents_id) <-> packed_contents(id, hash_sum, blob)
С названиями вакансий вряд ли имеет смысл делать аналогично.
