Правильное хранение и сквозной вывод изображений

Темы, не касающиеся фреймворка, но относящиеся к программированию в целом.
Ответить
Drugpunker
Сообщения: 187
Зарегистрирован: 2014.08.13, 19:44

Правильное хранение и сквозной вывод изображений

Сообщение Drugpunker »

Здравствуйте.
Столкнулся с проблемой в организации подхода.
Textarea заполняется текстом, включая html, в том числе есть и загрузка изображений.
То есть вставляемые изображения могут быть расположены в любом месте добавляемого текста.
Как хранить адреса данных картинок в отдельной таблице не придумал. Вернее не знаю как такое вообще делают.
И здесь прошу совета. Как это можно устроить.
Ну сохранить то имена файлов в отдельной таблице для изображений, я сохраню. А вот как выводить их потом в том самом месте, месте, где они визуально были добавлены?
Проблему эту пока не решил, поэтому храню прямо внутри текста, абсолютные пути.
Да,знаю, не правильно, поэтому в поиске решения.
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Правильное хранение и сквозной вывод изображений

Сообщение samdark »

Проблему эту пока не решил, поэтому храню прямо внутри текста, абсолютные пути.
И почему это проблема?
eXeCUT
Сообщения: 12
Зарегистрирован: 2016.05.30, 17:48

Re: Правильное хранение и сквозной вывод изображений

Сообщение eXeCUT »

Для таких целей я использую связку двух виджетов wysiwyg html-редактор и файловый менеджер KCFinder. Тут получается разделение обязанностей. Редактор отвечает за html, а файловый менеджер за картинки. Связь картинок с html зашиты в самом html и если картинка удалится каким-то образом, то эта связь будет битой.

Присоединяюсь к samdark и не понимаю цели их отделения от текста. Зачем хранить картинки в отдельной таблице? Тут наверное могут быть две задачи - делать какие-то операции с данными картинками или контролировать целостность связей картинок с текстом.
Drugpunker
Сообщения: 187
Зарегистрирован: 2014.08.13, 19:44

Re: Правильное хранение и сквозной вывод изображений

Сообщение Drugpunker »

samdark писал(а): 2020.09.01, 10:48
Проблему эту пока не решил, поэтому храню прямо внутри текста, абсолютные пути.
И почему это проблема?
Нуу, мало ли, часть пути изменится.
Придётся бегать по всем записям, парсить, заменять...
Например.
Drugpunker
Сообщения: 187
Зарегистрирован: 2014.08.13, 19:44

Re: Правильное хранение и сквозной вывод изображений

Сообщение Drugpunker »

eXeCUT писал(а): 2020.09.01, 14:17 Для таких целей я использую связку двух виджетов wysiwyg html-редактор и файловый менеджер KCFinder. Тут получается разделение обязанностей. Редактор отвечает за html, а файловый менеджер за картинки. Связь картинок с html зашиты в самом html и если картинка удалится каким-то образом, то эта связь будет битой.

Присоединяюсь к samdark и не понимаю цели их отделения от текста. Зачем хранить картинки в отдельной таблице? Тут наверное могут быть две задачи - делать какие-то операции с данными картинками или контролировать целостность связей картинок с текстом.
Вот как-раз таки в контроле целостности связей проблема.
Я учусь ещё только.
Рассуждая об этом, привожу аналогию с хранением, например, изображений товара.
Hasmany и т.п.
Или это в корне иной подход? И в моём случае нужно принять как есть? То бишь хранить абсолютные адреса средь прочего текста?
eXeCUT
Сообщения: 12
Зарегистрирован: 2016.05.30, 17:48

Re: Правильное хранение и сквозной вывод изображений

Сообщение eXeCUT »

Drugpunker писал(а): 2020.09.01, 14:54
eXeCUT писал(а): 2020.09.01, 14:17 Для таких целей я использую связку двух виджетов wysiwyg html-редактор и файловый менеджер KCFinder. Тут получается разделение обязанностей. Редактор отвечает за html, а файловый менеджер за картинки. Связь картинок с html зашиты в самом html и если картинка удалится каким-то образом, то эта связь будет битой.

Присоединяюсь к samdark и не понимаю цели их отделения от текста. Зачем хранить картинки в отдельной таблице? Тут наверное могут быть две задачи - делать какие-то операции с данными картинками или контролировать целостность связей картинок с текстом.
Вот как-раз таки в контроле целостности связей проблема.
Я учусь ещё только.
Рассуждая об этом, привожу аналогию с хранением, например, изображений товара.
Hasmany и т.п.
Правильные мысли. Тож страдаю в своём проекте из-за битых ссылок на изображения. Они часто приходят в негодность от времени.

Как вариант придумал такой колхоз, чтобы хранить данные связи:
1. При сохранении модели выдёргивать все адреса картинок из textarea парсером.
2. закачивать эти файлы в отдельную таблицу БД и связывать их с текущей записью ссылкой в БД. С опытом пришёл к выводу, что картинки идеально хранить в БД, а не файловой системе. Пропадает необходимость их бекапить и следить за путями. А вывод организовывать через приложение.
3. подменить в textarea перед сохранением все адреса на идентификаторы записей файлов в БД вида вроде {id файла}
4. При дальнейшем выводе значения textarea заменять эти идентификаторы на ссылку с контроллером, который выдёргивает этот файл из БД.

Тут целостность будет гарантировать БД за счёт ссылки на родительскую запись в таблице картинок.

Но мне не нравится сложность этого решения. Может быть есть и более простые варианты. Интересно узнать другие мнения.
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Правильное хранение и сквозной вывод изображений

Сообщение samdark »

Если у вас не миллионы текстов, то за десяток минут консольной командой можно обойти все тексты, выцепить все ссылки на картинки регулярками, сходить по HTTP проверить что там и выслать редактору отчёт о проблемах. Так вы не только обеспечите не битость своих картинок, но и также вообще любых картинок (и, если нужно, ссылок).
Drugpunker
Сообщения: 187
Зарегистрирован: 2014.08.13, 19:44

Re: Правильное хранение и сквозной вывод изображений

Сообщение Drugpunker »

samdark писал(а): 2020.09.01, 17:34 Если у вас не миллионы текстов, то за десяток минут консольной командой можно обойти все тексты, выцепить все ссылки на картинки регулярками, сходить по HTTP проверить что там и выслать редактору отчёт о проблемах. Так вы не только обеспечите не битость своих картинок, но и также вообще любых картинок (и, если нужно, ссылок).
Я себе также говорил, когда делал текущую реализацию.
Но мало ли, может есть что-то более подходящее. К этому спрашиваю.
Drugpunker
Сообщения: 187
Зарегистрирован: 2014.08.13, 19:44

Re: Правильное хранение и сквозной вывод изображений

Сообщение Drugpunker »

eXeCUT писал(а): 2020.09.01, 15:17
Drugpunker писал(а): 2020.09.01, 14:54
eXeCUT писал(а): 2020.09.01, 14:17 Для таких целей я использую связку двух виджетов wysiwyg html-редактор и файловый менеджер KCFinder. Тут получается разделение обязанностей. Редактор отвечает за html, а файловый менеджер за картинки. Связь картинок с html зашиты в самом html и если картинка удалится каким-то образом, то эта связь будет битой.

Присоединяюсь к samdark и не понимаю цели их отделения от текста. Зачем хранить картинки в отдельной таблице? Тут наверное могут быть две задачи - делать какие-то операции с данными картинками или контролировать целостность связей картинок с текстом.
Вот как-раз таки в контроле целостности связей проблема.
Я учусь ещё только.
Рассуждая об этом, привожу аналогию с хранением, например, изображений товара.
Hasmany и т.п.
Правильные мысли. Тож страдаю в своём проекте из-за битых ссылок на изображения. Они часто приходят в негодность от времени.

Как вариант придумал такой колхоз, чтобы хранить данные связи:
1. При сохранении модели выдёргивать все адреса картинок из textarea парсером.
2. закачивать эти файлы в отдельную таблицу БД и связывать их с текущей записью ссылкой в БД. С опытом пришёл к выводу, что картинки идеально хранить в БД, а не файловой системе. Пропадает необходимость их бекапить и следить за путями. А вывод организовывать через приложение.
3. подменить в textarea перед сохранением все адреса на идентификаторы записей файлов в БД вида вроде {id файла}
4. При дальнейшем выводе значения textarea заменять эти идентификаторы на ссылку с контроллером, который выдёргивает этот файл из БД.

Тут целостность будет гарантировать БД за счёт ссылки на родительскую запись в таблице картинок.

Но мне не нравится сложность этого решения. Может быть есть и более простые варианты. Интересно узнать другие мнения.
Ну да, костыльно.
Да и лишние действия при каждом выводе из бд, такое себе...
Вот как в соц.сетях интересно с этим делом?
Неужели так же...
Аватара пользователя
maleks
Сообщения: 1985
Зарегистрирован: 2012.12.26, 12:56

Re: Правильное хранение и сквозной вывод изображений

Сообщение maleks »

В некоторых цмс-ках они сразу к, допустим, статье дают возможность загрузки картинок, которые будут уже потом вставляться.
Варьируется подход.
- И когда эти картинки загружать, ведь при создании статьи ее id еще не известен.
- Как их загружать - с перезагрузкой страницы или налету.
- И как вставлять, можно шорткодом. Но если визивиг, то удобно все таки тегом <img>

Все это вполне реализуемо, а не просто когда любые картинки через файловый менеджер вставляешь в html.
Статья удаляется, а картинки нет.

В друпале 7, по моему, было это поразвитей сделано, и картиночки налету грузились и вставлялись по клику вставить
Yii2 universal module sceleton - for basic and advanced templates
Drugpunker
Сообщения: 187
Зарегистрирован: 2014.08.13, 19:44

Re: Правильное хранение и сквозной вывод изображений

Сообщение Drugpunker »

maleks писал(а): 2020.09.04, 14:27 В некоторых цмс-ках они сразу к, допустим, статье дают возможность загрузки картинок, которые будут уже потом вставляться.
Варьируется подход.
- И когда эти картинки загружать, ведь при создании статьи ее id еще не известен.
- Как их загружать - с перезагрузкой страницы или налету.
- И как вставлять, можно шорткодом. Но если визивиг, то удобно все таки тегом <img>

Все это вполне реализуемо, а не просто когда любые картинки через файловый менеджер вставляешь в html.
Статья удаляется, а картинки нет.

В друпале 7, по моему, было это поразвитей сделано, и картиночки налету грузились и вставлялись по клику вставить
Похоже, да, лишь только жёстко вписывать теги с абсолютами адресов, через визивиг.
По поводу "статья удаляется, а картинки нет".
Blob же есть.
Я как-то делал.
Если статья сохранена, имеем id.
С пом. Aftersave() ну или afterValidate(), пробегаем по всем img, лопатим из них img физические и сохраняем на сервере. Естесственно с заменой src.
Аватара пользователя
maleks
Сообщения: 1985
Зарегистрирован: 2012.12.26, 12:56

Re: Правильное хранение и сквозной вывод изображений

Сообщение maleks »

Это все костылики. Их минус в том что подведут при малейшем изменении хотелок.
В БД картинки на практике никто не хранит, кто не пробует, обжигается.
А всякие парсинги контента сильно муторные, да и смысл выбора картинок на сервере с вставкой абсолютным адресом в том, что выбираешь их из "сырого" хранилища. На одну и ту же картинку можно из разных статей сослаться.
Yii2 universal module sceleton - for basic and advanced templates
eXeCUT
Сообщения: 12
Зарегистрирован: 2016.05.30, 17:48

Re: Правильное хранение и сквозной вывод изображений

Сообщение eXeCUT »

maleks писал(а): 2020.09.07, 07:04 В БД картинки на практике никто не хранит, кто не пробует, обжигается.
Я наоборот намучился с хранением картинок в файловой системе из-за постоянно возникающих проблем с бэкапом и отладки пхп-кода по работе с превьюшками. Когда перешёл на БД вздохнул с облегчением. В чём сложности хранить их в БД? Наверное тут зависит от задач. Везде есть плюсы и минусы. Вот какие плюсы я вижу при разных подходах:
ФС:
  1. Операции над картинками можно производить любыми утилитами без участия ПХП или БД.
  2. Не нужна БД для функционирования картинок
  3. Для вывода не требуется участие приложения
БД:
  1. Контроль целостности картинок на уровне БД. Всегда есть гарантии, что картинка или её превьюшка не исчезнет. Бонусом появляется возможность привязать к картинке, например, текст описания в виде отдельного столбца
  2. Проще администрировать. Не нужно отдельно бэкапить или реплицировать на все сервера данные картинок.
  3. Взамен знаний о папках и правилах именования превьюшек в виде ПХП-кода приходит схема БД. SQL мне кажется для этого более удобнее. Можно обернуть всё в AR и работа с картинками станет такая-же удобная как и с другими данными.
Drugpunker
Сообщения: 187
Зарегистрирован: 2014.08.13, 19:44

Re: Правильное хранение и сквозной вывод изображений

Сообщение Drugpunker »

eXeCUT писал(а): 2020.09.07, 10:48
maleks писал(а): 2020.09.07, 07:04 В БД картинки на практике никто не хранит, кто не пробует, обжигается.
Я наоборот намучился с хранением картинок в файловой системе из-за постоянно возникающих проблем с бэкапом и отладки пхп-кода по работе с превьюшками. Когда перешёл на БД вздохнул с облегчением. В чём сложности хранить их в БД? Наверное тут зависит от задач. Везде есть плюсы и минусы. Вот какие плюсы я вижу при разных подходах:
[/list]
БД:
  1. Контроль целостности картинок на уровне БД. Всегда есть гарантии, что картинка или её превьюшка не исчезнет. Бонусом появляется возможность привязать к картинке, например, текст описания в виде отдельного столбца
  2. Проще администрировать. Не нужно отдельно бэкапить или реплицировать на все сервера данные картинок.
  3. Взамен знаний о папках и правилах именования превьюшек в виде ПХП-кода приходит схема БД. SQL мне кажется для этого более удобнее. Можно обернуть всё в AR и работа с картинками станет такая-же удобная как и с другими данными.
Может быть и удобно.
Но если изображений много, и количество их постоянно увеличивается, будут проблемы.
eXeCUT
Сообщения: 12
Зарегистрирован: 2016.05.30, 17:48

Re: Правильное хранение и сквозной вывод изображений

Сообщение eXeCUT »

Drugpunker писал(а): 2020.09.07, 15:56 Но если изображений много, и количество их постоянно увеличивается, будут проблемы.
С производительностью проблемы? Как и с любой другой проблемой производительности БД это решаемо стандартными подходами оптимизации. Да и мне кажется редко где нужно хранить так много картинок, чтобы БД начала тормозить.
Ответить