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

Тема в разделе "SQL", создана пользователем zloi, 7 янв 2008.

Статус темы:
Закрыта.
  1. zloi

    zloi Гость

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

    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.
     
  3. diff

    diff Гость

    vy budete sil'nee nagrujat' mysql - poyavyatsya lishnie zaprosy
    ps
    ne vse napisanno v knigah, ochen' mnogoe uznaesh' vo vremya raboty(na praktike)
     
  4. zloi

    zloi Гость

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

    diff Гость

    a vy podumaite golovoi, prejde chem floodit', otkuda berutsya zaprosy i pochemu mogut poyavitsya lishnie.
     
  6. European

    Регистрация:
    4 сен 2006
    Сообщения:
    2.580
    Симпатии:
    0
    Для: diff
    Если Вы хранитель Высших знаний, то поделитесь ими с народом и не нада хорохорится. Конкретно ответьте на вопрос: что такое лишние запросы и откуда они берутся?
     
  7. zloi

    zloi Гость

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

    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'.
     
  9. European

    Регистрация:
    4 сен 2006
    Сообщения:
    2.580
    Симпатии:
    0
    Для: diff
    Я так и думал, что у вас никаких конкретных фактов, только личный опыт, который ИМХО не совсем корректен. Я согласен c sax_ol, он вам уже пояснил выше
     
  10. diff

    diff Гость

    Для: European
    ochen' rad, shto vash opyt korrekten :lol:
     
  11. root

    root Гость

    Для: zloi
    http://www.microsoft.com/technet/prodtechn...1.mspx?mfr=true
    Код (Text):
    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.
    В большенстве случаев ИМХО лучше в базе хранить.
     
  12. European

    Регистрация:
    4 сен 2006
    Сообщения:
    2.580
    Симпатии:
    0
    Для: diff
    Вот вам root подтверждение выложил
     
  13. European

    Регистрация:
    4 сен 2006
    Сообщения:
    2.580
    Симпатии:
    0
    Для: diff

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

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

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

    Вот цитата с одного из форумов:
    Ну что же, приведу ссылку, полностью отражающую мое мнение (обратите внимание на выводы):
    http://www.opennet.ru/base/dev/blob_mysql.txt.html
    А вот ближе к SQL Server:
    http://job57.narod.ru/asp2/29/index.htm

    А вот ссылка, доказывающая обратное (вот только авторитетность ее сомнительна):
    http://www.host.ru/support/articles/mysql-optimization.html

    И вот десятки страниц полемики, не выявившей победителя:
    http://xpoint.ru/forums/computers/dbms/mis...ead/13645.xhtml
    http://www.hostforum.ru/archive/index.php/t-2524.html
    http://www.sql.ru/forum/actualthread.aspx?tid=512451

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

    maykoff Гость

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

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

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

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

    zloi Гость

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

    Регистрация:
    4 сен 2006
    Сообщения:
    2.580
    Симпатии:
    0
    <!--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 стал суперпроизводительной базой? Ой как сомневаюсь...
     
  17. Holger Dee Assuran

    Holger Dee Assuran Гость

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

    Регистрация:
    4 сен 2006
    Сообщения:
    2.580
    Симпатии:
    0
    <!--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]
    От такой базы бежать нужно как от огня. Такое же голословное утверждение как и ваше
     
  19. Holger Dee Assuran

    Holger Dee Assuran Гость

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

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

    А это я вобще не понял про что...

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

    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.
     
Загрузка...
Статус темы:
Закрыта.

Поделиться этой страницей