Форум MySQL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Как?


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

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

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