Форум MySQL

Всё, я дозрел до того, чтобы рисунки хранить в базе.
Видимо меня даже не остановит то, какое великое преобразоание всего хозяйства при этом мне грозит.
Одного только боюсь,что заложу какой-нибудь косяк в основу. Не учту что-нибудь важное.
Подсажите, что должен включать в себя скрипт сбора картинок в базу.
(Картинки, кстати, не очень мелкие, не аватары)
1) Правильно ли я полагаю, что нa расширения картинки gif, png итд полагаться нельзя? Что надо тип файла выяснять иначе, и хранить его в отдельном поле, чтобы потом правильный заголовок послать? Может для этих целей что-то уже готовое есть?
2) Надо ли использовать "преобразование"? Или только больше путаницы будет?
В общем, помогите сориентироваться со стратегией в целом.
Хочу все картинки в таблицу упрятать и отдавать их одним и тем же PHP скриптом выбирая по GET параметру.

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

Если говорить в общем, то работать с базой на виртуальном хостиге несравненно удобнее, чем с файловой системой, возможности использования которой ещё и урезаются почему-то владельцами хостингов (запрещают, напимер, link и symlink).
В результате получается, что если в какой-то функции где-то исправил ошибочку, то надо править потом ещё 10 файлов, в которых та же функция определяется.
Как бы это объяснить?
Вот такие ссылки include "..utils/my_lib.inc" - создают проблемы при модификации сайта из-за того,что связи вообще рвутся и ничего не работает потом, а
такие include "utils/my_lib.inc" - постоянно остаются не исправленные функции у части библиотек.

В итоге, когда скриптов становится действительно много, всё выходит из-под контроля окончательно: Исправляешь что-то и уже не реально проверить всё на предмет,а вдруг при этом что-то где-то упало?

Поэтому я собрался ограничиться теперь 3 файлами: Один index.php будет подгружать необходимые скрипты из базы, второй image.php будет отдавать картинки из базы Третий css.php будет таблицы стилей отдавать. В базе можно добиться необходимой гибкости связей между файлами,чего не получается достигнуть в файловой системе.

Но это я в общем говорю, может быть на практике никогда бы и не собрался так сделать.
Но теперь вот мне надо срочно утрамбовать кучу статей в базу. А картинки куда? Сложить их большой кучей? Или создать кучу папочек? Этого не хватит для дальнейшей работы. По мере сортировки статей картинки в базе будут оснащены целым рядом атрибутов: размеры, цветность, классификационные индексы. Всё это со временем рассыплется, если будет указывать на файловую систему и гарантия синхронности удаления будет отсутствовать.

Хорошо, а почему файлу image.php не брать файлы из каталога данных, а не из базы? Пусть изображения ищет и формирует скрипт - в базу-то зачем изображения помещать? Вам все-равно от сайта к сайту придется указывать параметры базы данных (в одном месте), а тут будете указывать параметры каталога, где храняться изображения (тоже в одном месте). Зато съэкономите массу процессорного времени, которое MySQL потребляет очень много. Врочем это не важно, если будете ссылаться на файл image.php - в любой момент данные сможете кэшировать. Только учитывайте тот факт, что при переносе дампа вы можете его побить и тогда у вас пропадут все изображения - если делаете дамп - всегда проверяйте его на работоспособность.

>Хорошо, а почему файлу image.php не брать файлы из каталога данных, а не из базы? Пусть изображения ищет и формирует скрипт - в базу-то зачем изображения помещать?

В принципе, не обязательно помещать, но базы потому и загружены так сильно,что в них удобней всё хранить. Если MySQL вставит интерпретатор PHP в себя, то и вообще почти вся нагрузка будет на базах. Вы считаете, что извлекать картинку из базы дольше, чем из файловой системы?


>Вам все-равно от сайта к сайту придется указывать параметры базы данных (в одном месте), а тут будете указывать параметры каталога, где храняться изображения (тоже в одном месте). Зато съэкономите массу процессорного времени, которое MySQL потребляет очень много.

Засчёт чего может возникнуть экономия? И,если можете, то в процентах, ну, хоть примерно!

>Врочем это не важно, если будете ссылаться на файл image.php - в любой момент данные сможете кэшировать.

Как?


Только учитывайте тот факт, что при переносе дампа вы можете его побить и тогда у вас пропадут все изображения - если делаете дамп - всегда проверяйте его на работоспособность.

Аналогично и с архивом картинок :)

>Вы считаете, что извлекать картинку из базы дольше, чем из файловой системы?
Конечно, файловая система всегда быстрее базы данных работает. Так как база данных - это надстройка над файловой системой. К нескольким файлам-изображений получить доступ проще, чем к тем же изображениям упакованным в один файл-таблицу.

>Засчёт чего может возникнуть экономия? И,если можете, то в процентах, ну, хоть примерно!
За счет процессорного времени - доступ к файловой системе у вас будет стабильно потреблять 3-4% процессора, доступ к MySQL до 80%.

>>Врочем это не важно, если будете ссылаться на файл image.php - в любой момент данные
>>сможете кэшировать.
>Как?
Он будет один на весь проект - если возникнут проблемы, вам потребуется переписать лишь его одного, а не перелопачивать весь проект. В конце концов, можно будет сохранить все изображения на жесткий диск и составить таблицу для этого проекта. Т.е. матрица изображений по прежнему будет находиться в базе, а пользователи реально будут обращаться к копиям на жестком диске.

>Аналогично и с архивом картинок :)
Архив по определению бинарен - дамп зачастую рассматривается как текстовый файл, откроете в текстовом редакторе, некоректно работающем с бинарными данными, поправите - и все на картинках можно будет крест ставить.

>Архив по определению бинарен - дамп зачастую рассматривается как текстовый файл, откроете в текстовом редакторе, некоректно работающем с бинарными данными, поправите - и все на картинках можно будет крест ставить.

Вот это любопытно!
Получается, что дамп с картинками нельзя в текстовом редакторе править?
Или вы подскажете какой всё-таки редактор позволяет править?

Конечно нельзя. Если нужно редактировать именно дамп (изображения), то любым HEX-редактором. Но зачем?

>Конечно нельзя. Если нужно редактировать именно дамп (изображения), то любым HEX-редактором.

Я имел в виду не сами изображения, а состав дампа.
Разрезать его на куски, например, не трогая бинарных фрагментов.
Такое возможно в каком-то редакторе?

А вы получите такой дамп смешанный и посмотрите как он будет выглядеть. Ничего страшного не произойдет, если до/после строку подредактировать, но вот, если при записи, произойдет вставка лишнего куда не следует, тогда капец.)
А вообще, держать большие изображения в базе это мрак.

>А вы получите такой дамп смешанный и посмотрите как он будет выглядеть.
Так это ж зависит от того, каким редактором смотреть.
Я и спрашиваю, может, вы знаете такой редактор, который нормально отобразит и не будет лишнего вставлять.

>А вообще, держать большие изображения в базе это мрак.
Из-за нагрузки на процессор, да? Но процессор у сервера чаще всего не самое узкое место.
Поэтому на производительности это, вроде, не дожно сказаться, почти. Или есть ещё какая-то причина, о которой я не догадываюсь?

Картинки-то не очень и большие, не аватары, конечно, но умеренно весят, не перегружают html страницы.

Хотелось бы всё-таки до конца разобраться, а то вы меня с Хеопсом напугали, теперь я уже сомневаюсь сильно, а ясного понимания проблемы так пока и не возникло...

Да ни кто не пугает ) Лично я думаю также как и Хеопс, не место изображениям в базе, если это не мелочь типа аватарок. В базе можно описать всю подноготную изображения, а вот его само держать в папке. Что касается неудобства смены/редактирования места назначения в таком случае, то ни кто не мешает держать в базе ссылку на конфигурацию, котороая будут сосредоточена в одном месте.
Я пользуюсь HomeSite, кторый ничего лишнего без моего ведома не вставляет.

Ладно, спасибо вам и Хеопсу, что наставили на путь истинный!
А то чуть не занесло на повороте...