Хранение картинок

  • Автор темы zloi
  • Дата начала
Статус
Закрыто для дальнейших ответов.
Z

zloi

Народ, ай нид хелп.
Как в таблицу добавить картинку там или просто какой-нить файл, а потом нормально оттуда выдрать? А то очень нада, чтоб все одним куском лежало.
 
D

diff

dlya dobavleniya kartinki v bazu dannyh, nujno snachala ee prochitat', zatem vstavit' dannye v pole s tipom binary.
No etogo delat' ne sleduet, potomushto tem samym vy budete sil'nee nagrujat' mysql - poyavyatsya lishnie zaprosy, luche hranite kartinku v special'noi papke, a v tablice ih url i local'ny adress.
 
Z

zloi

to sax_ol
а можно немного поподробнее и поконкретнее?
а то я второй раз справочник Викрама Васвани перечитал и ничего не нашел
 
E

European

Для: diff
Если Вы хранитель Высших знаний, то поделитесь ими с народом и не нада хорохорится. Конкретно ответьте на вопрос: что такое лишние запросы и откуда они берутся?
 
Z

zloi

to sax_ol
и PHP в том числе, но не только, так, для общего развития тоже.
если Вы хотите дать пример, то можно на PHP, разберусь :blink:
 
D

diff

ya ne horohorus', prosto eto ochevidno.
izvenite, ya ne hotel nikogo obidet' ili isportit' nastroenie, a tem bolee nachinat' spory. vot moi argument:
lishnii zapros, eto k primeru zapis' izobrajeniya v DB, a zatem ego zagruska, eto kazaetsya DB, a escho nujno budet pisat' obrabotchik na kakom-nibud' yazyke(php\perl\etc), kotory budet ee vyvodit eto toje zatraty po proizvoditel'nosti.
v celyah experementa ochen' udobno napisat' takoe prilojenie(dlya sebya), no esli u vas skajem poseshaemost' 10000-100000 uniq\daily, to optimizaciya budet neobhodima dlya snijeniya nagruzki na vash server ili vds, zachem potom podnimat' etot vopros, esli mojno srazu etogo izbejat'.
 
E

European

Для: diff
Я так и думал, что у вас никаких конкретных фактов, только личный опыт, который ИМХО не совсем корректен. Я согласен c sax_ol, он вам уже пояснил выше
 
R

root

Для: zloi

Код:
Database or File System

Web applications often have graphics associated with tabular data. For example, real estate Web sites typically include photographs of homes for sale. On company intranet sites, client databases can contain image files of client products. For such applications, a common design question involves whether the images should be stored in the database or in a file system. In most cases, the best choice is to store the images in the database together with the other data. 

Storing the images in a database is the better choice if the application in which the images will be used count on the benefits of a database system. The benefits of storing the images in the database include: •	
Scalability. Although file systems are designed to handle a large number of objects of varying sizes, file systems usually are not optimized for a huge number (tens of millions) of small files. Database systems are optimized for such cases. 

Availability. SQL Server has availability features that extend beyond those provided by the file system. •	
SQL Server replication is a set of solutions that allow you to copy, distribute, and potentially modify data in a distributed environment. 
•	
Log shipping provides a way of keeping a stand-by copy of a database in case the primary system fails. 



Storing images in a file system would be a better choice if: •	
The application in which the images will be used requires streaming performance, such as real-time video playback. 
•	
BLOBs require frequentaccess by applications, such as Microsoft PhotoDraw® or Adobe Photoshop, which only know how to access files. 
•	
You want to use some specific feature in the NTFS file system such as Remote Storage. 


As with most guidelines though, these points can assist in decision making only after a thorough research of the specific use, environment, and purpose of the application.
В большенстве случаев ИМХО лучше в базе хранить.
 
E

European

Для: diff
Вот вам root подтверждение выложил
 
E

European

Для: diff

Кстати, благодаря подписке получил Ваше отредактированное сообщение и вот что отвечу.

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

a kakie facty vy by hoteli videt'? o kakoi konkretike idet rech'? vam nujny testy na win\nix serverah? V chem problemma, mojno ih sdelat', ya uveren, shto u vas vse poluchitsya, pojalusto provedite takoi test i pokajite ego rezul'taty.

Вообще проблема хранения картинок на диске или в базе - это одна из программерских holy war, и я никак не изменю расстановку сил на данном фронте. Топикстартер начинал речь про MySQL, вы говорите также про нее. К сожалению, я не имею абсолютно никакого опыта общения с MySQL, но по анализу аналогичных веток на других форумах и различных статей пришел к выводу, что для MySQL - это непомерно сложная задача. Странно, у более крупных СУБД с этим проблем нет.

Вот цитата с одного из форумов:
то что хранение файлов в mysql - плохо, доказано phpclub 'ом

vy ved' sami nichego ubeditel'nogo ne skazali, krome togo, shto postavili pod somnenie moi sovet: nedelat' tak v real'nyh situaciyah.
Ну что же, приведу ссылку, полностью отражающую мое мнение (обратите внимание на выводы):

А вот ближе к SQL Server:


А вот ссылка, доказывающая обратное (вот только авторитетность ее сомнительна):


И вот десятки страниц полемики, не выявившей победителя:




P.S. почему кириллицей писать не можете?
 
M

maykoff

Не удержался и решил вставить своё ИМХО.

Картинку в базу - очень просто - считал в строку файл и записал в бинарное поле (blob)
Вычитать - обычным способом, перед выводом указать соответствующие заголовки.

Теперь попытаюсь отговорить. Как я понял - речь идёт о пхп и мускле.
1. Зачем это всё? Для такого геморроя должны быть веские основания.
2. мускль - очень быстрая база, она хорошо обрабатывает большое количество мелких запросов (более миллиона записей - а она летает). Но обрабатывать большие записи (мегабайтные картинки) ей тяжело. 3. При обработке графики ощутимо грузится сервер. Одно дело - ссылка на файл, лежащий на сервере, другое - вычитать запись из базы (разумеется - в строку, выжрав при этом изрядно памяти, в то время как вывод файла из файловой системы происходит вообще без участия php). Потом эту строку вывести. Принтом или ехом. Когда выводятся большие куски хтмля - рекомендуется выводить его напрямую, без обработки php. На этом основана работа такого замечательного шаблонизатора, как смарти. А тут мы выводим посредством php графический файл.
3. Для чего нужна база данных? В первую очередь - для того, чтобы быстро можно было оперировать данными, изменять, осуществлять поиск. Если файл один раз загрузили, а потом только читают - нужно ли его держать в базе?
4. И наконец - ограничение файловой системы на размер файлов базы. Тяжело перевалить за 4 гига, когда в базе индексы, названия файлов и категории. Но когда в базе сами файлы( по сотне метров каждый) - то это может превратиться в реальную проблему.

Достоинств этого метода хранения данных я не вижу не одного. Разве что какие-то специфические требования.
 
Z

zloi

to European
а Вы вобще сами смотрели те ссылки, которые порекомендовали? Наврядли, потому-что ссылки на форум 2002-го года, где обсуждается быстродействие MySQL выглядят по крайней мере странно...
 
E

European

<!--QuoteBegin-zloi+11:01:2008, 23:33 -->
<span class="vbquote">(zloi @ 11:01:2008, 23:33 )</span><!--QuoteEBegin-->а Вы вобще сами смотрели те ссылки, которые порекомендовали?
[snapback]93164" rel="nofollow" target="_blank[/snapback]​
[/quote]
Не поверишь, не только смотрел, но и внимательно читал. И я их не рекомендовал, а только привел к сведению. А что 2002 год? Неужели за это время MySQL стал суперпроизводительной базой? Ой как сомневаюсь...
 
H

Holger Dee Assuran

Полностью согласен с maykoff - вы конечно можете засунуть картинки в базу MySQL, но как говорят разработчики и показывает личный опыт - это далеко не самый удачный способ. База сильно теряет в производительности при таких объемах обрабатываемой информации.
 
E

European

<!--QuoteBegin-Holger Dee Assuran+30:01:2008, 12:12 -->
<span class="vbquote">(Holger Dee Assuran @ 30:01:2008, 12:12 )</span><!--QuoteEBegin-->База сильно теряет в производительности при таких объемах обрабатываемой информации.
[snapback]95770" rel="nofollow" target="_blank[/snapback]​
[/quote]
От такой базы бежать нужно как от огня. Такое же голословное утверждение как и ваше
 
H

Holger Dee Assuran

При каких таких?
Я имею в виду объемы данных соразмеримые с объемом скажем фотогаллереи наполненной тысячами фотографий, к примеру в jpeg-формате. Скажем максимальный размер картинки не привышает 450х400 пикселей. Я не скажу на вскидку сколько это в байтах, да это и не важно - один фиг больше чем просто текстовая ссылка на файл. В результате база дольше держит соединение с одним пользователем, с другим, с третьим а ведь количество соединений небезгранично. Вот вам и потеря производительности.

От такой базы бежать нужно как от огня
ИМХО MySQL-лучшее что можно придумать для web - быстро и надежно, главное руки и голова из нужных мест чтобы росли. А файло должно храниться в папках а не в базе.
А монстры типа MSSQL просто вымрут за ненадобностью и чудовищностью.

Такое же голословное утверждение как и ваше
А это я вобще не понял про что...

Модератор: последнее китайское, не в пивной!
 
P

Pasha

<!--QuoteBegin-Holger Dee Assuran+30:01:2008, 17:27 -->
<span class="vbquote">(Holger Dee Assuran @ 30:01:2008, 17:27 )</span><!--QuoteEBegin-->ИМХО MySQL-лучшее что можно придумать для web - быстро и надежно, главное руки и голова из нужных мест чтобы росли. А файло должно храниться в папках а не в базе.
А монстры типа MSSQL просто вымрут за ненадобностью и чудовищностью.
[snapback]95853" rel="nofollow" target="_blank[/snapback]​
[/quote]Быстро ИЛИ надежно. Транзакции ведь бесполезная вещь, кто ими вообще пользуется.

Если MSSQL тормозит - значит руки не оттуда растут. И файло на дисках он сам умеет хранить (2008-й), погугли по слову FILESTREAM.
 
Статус
Закрыто для дальнейших ответов.
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!