Форум PHP

Скажите пожалуйста. Можно ли используя MySql хранить в БД файлы jpg и swf для того чтобы потом их извлекать из базы данных и вставлять в php страницу чтобы они отображались как например результат применения <img src = “”>?

Можно

А как? Или где можно узнать подробней?

Вы уверены, что вам нужно хранить в БД именно файлы, а не их имена или адреса?

Я думал об этом. Я не уверен окончательно. Но было бы удобнее хранить их в БД, не создавая папки. Единственное, что может меня разубедить в этом - это катастрофическое падение скорости. Ну или сильно заметное.

Так и будет!

Может так и будет. Но плюсов пока я вижу больше. Не нужно никаких каталогов создавать (это меня напрягает больше, чем небольшое замедление в работе). Просто я уделяю организации хранения файлов большое внимание. Именно БД в этой организации, на мой взгляд, идеальное решение.

Кодируйте в Base64 и храните.

Зачем кодировать?

почему не морзянкой?

Каталоги можно заменить на БД, храня физически все файлы в одном каталоге.

Вы сперва испробуйте свое "идеальное" решение во всех ракурсах...

Вы собираетесь производить анализ изображения средствами СУБД?
Скорее всего это не так. Весь анализ сведется к поиску и сортировке изображений по имени (уникальному идентификатору, времени добавления, категории и тд.). Именно ту информацию с которой Вы будете работать (а основная работа СУБД связана с поиском и сортировкой) и нужно хранить в БД. А гонять мегабайты между сервером MySQL и Apache просто так, не рационально мягко говоря.
я уделяю организации хранения файлов большое внимание
поясните этот момент.
но в любом случае из базы нужно гнать пинками все то, что лежит "мертвым грузом".
Единственное, что может меня разубедить в этом - это катастрофическое падение скорости. Ну или сильно заметное.
а теперь небольшое лирическое отступление.
Представьте, что Вы начальник склада. У Вас на складе (файловая система) всё лежит на полочках (директориях), тишина, красота и гармония. Вас попросили отгрузить пять двухсот литровых бочек синтетического масла определенной фирмы (фотографии), Вы звоните на второй этаж в центр координации тете Даше (БД), и просите принести информацию на какой полке и под каким номерком лежит то что нужно выдать. Тетя Даша одевает туфельки на высоких каблуках, берет папочку с нужными документами и спускается к Вам.
Теперь представьте, что все бочки лежат в центре координации..... Вы звоните и говорите, тетя Даша мне срочно нужно пять двухсот литровых бочек... тетка одевает оранжевый жилет, грузит на себя тонну и галопом несется со второго этажа со всеми вытекающими последствиями.... страшно?

Ну, да. Страшно. Если это так, то тогда правильнее хранить пути, а не файлы, чтобы не нагружать тётю Дашу. Но неужели нет замены тёте Даше? Может есть такая СУБД. Как Шварцнегер, и сильный и умный :)) Если есть то отпишитесь. Жаль, что MqSql на эту роль не подходит.

Да зачем это всё? Почему вы так боитесь файлов?
В конце концов, БД - это тоже файл, только один и большой.

Интереснее :))) Но жертвовать производительностью ради интереса не готов. Вот и уточняю :) Не пойму. Зачем вообще тогда такие типы полей предусмотрены, которые позволяют хранить большой объём информации? Если в итоге её рациональнее хранить в файле? Только для безопасности что-ли? Или просто это не доработано в MySql?

Поле BLOB, которое вы имеете в виду, позволяет хранить не "большие объёмы", а двоичные данные. Зачем это нужно - на всякий случай. Файлы там тоже можно хранить, но это примерно как носить картошку в дамской сумочке - можно, просто, удобно, но глупо)

Самопроизвольно появился вопрос. А в каких случаях оправдано хранить двоичные дынные в поле BLOB. Кто-то это уже использовал?

Вы определенно издеваетесь....

Да почему издеваюсь! Мне интересно! Киналь написал:
> Зачем это нужно - на всякий случай.
Вот, и мне стало интересно. А на какой такой всякий случай. Кто-то этим уже пользовался или нет.

пишу третий раз (!!!)
Именно ту информацию с которой Вы будете работать (а основная работа СУБД связана с поиском и сортировкой) и нужно хранить в БД

Спокойствие, только спокойствие :)
Вот мне и интересно, какая информация размером 4 Гб может использоваться для поиска и сортировки например изображений. Что это за информация? Не может же путь к файлу быть подобен "Войне и Мир" Толстого! Или какое либо значение для сортировки, такого размера. Получается бред какой-то. Эти возможности предоставленные СУБД то же что дамская сумочка для солдата которую ему дают перед боем. Выбросить её нужно! И давать её не нужно получается, чтобы людей не запутывать! Если я не ошибаюсь, последняя верся MySql позволяет хранить ещё больший объём данных в поле. А зачем? Ну нет таких данных для поиска файла, которые будут весить хотябы в половину разрешённого веса! Или есть? Вот, что это, просто неиспользуемая обсалютно возможность. Или может быть я чего-то не знаю?

Нет блин... MySQL разрабатывали спецом шоб Вы хранили там свои фотки или под Вашу госевуху.
База абстрагирована от хранящихся данных, ей достаточно знать кокой у этих данных тип, чтобы выполнять конкретные действия с этим типом данных.
Вы знаете что такое Google? если не сбрехал источник где я это читал, то там в базе MySQL 60000 таблиц, содержащих до 5 миллиардов строк....
еще вопросы будут?
_____
я спокоен как танк

Вопросы будут. Но не по этой теме. Я для себя пришёл к выводу, что если есть небольшой проект, и он не планирует развиваться и через некоторое время быть похожим на Гугл (или что-то другое, но большое), то MySql с удовольствием поработает с картинками сохранит и защитит их. Но если в планах развивать проект, и он будет хранить большое количество данных, то хотя MySql и поддерживает хранение, например картинок и знает, как с ними работать, но их хранение и извлечение будет нагружать систему, и нужно будет раскошеливаться на оборудование, и испытывать некоторые неудобства со скоростью обработки запроса. А для себя нужно решить, каким проект будет… Спасибо. Много интересного узнал.

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

Я полностью с Вами согласен. И считаю, что на форуме можно получить, только начальные представления о чеё либо. А книжки у меня есть и я их с удовольствие читаю. Вот только почему то, данного вопроса нигде не встречал. Может потому, что у меня книги для новичков. А может и ещё по чему. На всё нужно время. :) Может, что посоветуете почитать?

у Вас какая книга именно по MySQL?
___
у меня http://softtime.ru/sql/?id_article=84
но тогда еще не было этой http://softtime.ru/sql/?id_article=104 - её я скорее всего куплю в ближайшем времени, жаль что автограф авторов получить проблематично :)

и еще вот эта http://www.dialektika.com/books/978-5-8459-1167-4.html
тут полнее описаны принципы нормализации и т.д.

Ну, что я говорил. Есть же Люди!
У меня такая http://www.kniga.ru/books/145450
Такую только купил (там немного есть).http://softtime.ru/php5/?id_article=117
И такая http://softtime.ru/php5/?id_article=94 (тоже немного затрагивает MySql).
Вот эта заинтересовала http://www.dialektika.com/books/978-5-8459-1167-4.html ( я люблю когда много страниц :).
Всё бы почитал, да где взять 100 часов в сутки? И большую голову :)
Тоже без афтографов. Пока :)

что-то я в последнее время все чаще и чаще начал себя цитировать.....
Именно ту информацию с которой Вы будете работать (а основная работа СУБД связана с поиском и сортировкой) и нужно хранить в БД
загрузить целиком и достать целиком - это не тот случай.
А вот если бы тетя Даша для того чтобы отобрать нужное масло проводила химический анализ на молекулярном уровне, то да смысл хранить это на "втором этаже" есть. Но это уже был бы не центр координации с одним компьютером, а целая химическая лаборатория соответственно требующая значительных денежных затрат, не только на исследование, но и для хранения всей этой лабуды.
Вы готовы платить бабло за хранение на "втором этаже", если на первом вся эта хрень может лежать бесплатно? (раз уж ненужная транспортировка Вас не пугает, хотя если подумать то грузчикам или оранжевой тете Даше все равно за это придется платить, бесплатно только мухи какают где попало)
____
Может есть такая СУБД. Как Шварцнегер, и сильный и умный
есть..... MySQL называется
Вы зря недооцениваете возможности этой БД. Самым узким местом тут будет выступать платформа на которой работает эта база данных (грубо говоря проц, оператива и дисковый массив)

"Склеивать" картинки в кучу оправдано в видеофайле, например. С чего вам понадобилась их "склеивать" ради хранения? Потому, что лень создавать папки? Так с таким же успехом можно хранить все изображения в одной папке, и при этом свободно в ней ориентироваться.