Одна таблица для изображений
Предлагаю добавить единую таблицу с изображениями
Структура:
- id
- name
- type (тип изображения product/category/brand)
- type_id (ид товара/категории/бренда)
- filename
- position
Что решает?
- Можно загружать любые изображения в разных модулях, в неограниченном количестве. Например сейчас есть ограничение на загрузку одного изорбажения в категорию или бренд. Для post и blog вообще отсутствует фукнция загрузки изображений.
- Единая система ресайза изображений (сейчас в движке ресайзятся только product)
- Единый модуль для работы с изображениями
- Удаление лишних колонок в таблицах __brands (image), __categories (image) итд.
- Удаление лишних функций для работы с изображениям и в /api/brands.php delete_image(), /api/Categories.php delete_image() итд.
отличная идея, и сделать скажем так свой сторадж рисунков так же нужно научить ресайдить с вложенностью.
На неделе сделаю коммит, есть кое какие наработки.
- Мне кажется функции удаления не лишние в любом случае. При удалении все равно нужно удалять картинку,
- type и type_id не нужны, в них нет никакого смысла, айди достаточно,
- Ресайз работает, если изображения в папке той-же что и изображения товаров, переделывать особо не нужно ничего.
- это касается удаление рисунка загруженных старым методом. Нету смысла делать прокси типа
- нужны что бы знать что данный рисунок относится к товару или к бренду
- часто бывает случаи когда нужно сделать к примеру галерею в бренде или еще где то.
- Да понял, централизованная функция и ее вызов пойдет,
- Зачем знать? Мы и так знаем кому какие картинки по связи айди,
- Да, я понял, я говорю что это работает уже если просто сменить папку источника.
у товара и категории могут быть ид одинаковый
Дается мне что для связи 1 ко многим нужны будут дополнительные таблицы связи картинки с категорией, страницей итд, и никаких вопросов в этой уже не возникнет, потому что айди картинок все уникальные. Или добавить этот тип в одну таблицу всех связей, а не к картинке.
А, ну понял, вы хотите вообще все таблицы эти убрать. Мне кажется это не оптимально.
Мне кажется это не оптимально.
в чем проявляется не оптимальность? Скорость работы - не аргумент, тестировал на 3+ млн записях в БД, никаких просадок не увидел.
ок