Форум PHP

Добрый день. Возник вопрос, как правильно организовать систему аватарок для пользователей сайта? В процессе мышления возникло несколько вариантов:

I способ: хранить картинку на сервере в отдельной директории, а в базе данных в таблице с пользователями хранить у каждого пользователя название картинки и в нужный момент картинку подключать.

II способ: хранить картинку в базе данных в отдельной таблице, и в таблице пользователей ID на эту картинку, и загружать картинку напрямую с базы данных.

Какой из этих способов считается более гуманным? Если есть другие варианты, пожалуйста предложите.

Первый. Меньше будет нагрузка на сервер.Только позаботьтесь об уникальности имени файла аватарки.

Только позаботьтесь об уникальности имени файла аватарки
нужно использовать id_user в качестве имени файла на диске :)

Тогда будет, как говорится, «вторая пара сапог даром»=)

Ага, точно! xD

Картинки, конечно, лучше хранить на диске, а информацию для доступа (имя файла и его связь с конкретным пользователем) к ним в БД.

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

Я лично поступаю так: имя файла по некоторому алгоритму преобразуется в уникальный код, длиной, скажем 32 символа. Например:

Допустим, мы пишем все файлы в папку /files/

Создаём для загруженного файла уникальное имя, скажем dfrt4dRtfgftdt4lnfd88fvdsf6nmgt7.jpg

Далее, при записи файла на диск откусываются первые 2 символа и создаётся поддиректория с таким названием куда пишется наш файл /files/df/rt4dRtfgftdt4lnfd88fvdsf6nmgt7.jpg . Далее, путь к файлу вместе с id записывается в таблицу БД.

Таким образом распределение файлов по папкам идёт достаточно равномерно и ситуация, когда в одной папке слишком много файлов практически исключается.

Создаём для загруженного файла уникальное имя, скажем dfrt4dRtfgftdt4lnfd88fvdsf6nmgt7.jpg
я же написал чуть выше что нужно использовать для имени файла?
зачем что-то создавать, что уже есть и его нужно просто взять

Чтобы исключить скопление большого количества файлов в одной директории. Механизм, предложенный Axxil, отличается тем, что позволяет хранить огромное количество файлов, не опасаясь того, что при первом обращении папка с ними будет только пару минут читаться.

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

Во-первых не предложили, а во-вторых вы будете тратить ресурсы для вычисления папки, а в варианте Axxil её можно очень быстро извлечь из имени. Файлы загружаются реже, чем отображаются, поэтому выгода есть. А кэшировать можно не только папки, но и хэши для создания новых файлов, тем более, что уникальность можно обеспечить тем же идентификатором, а не уникальные хэши создаются быстро, да и заранее их можно заготовить.

Да, хеши можно кешировать в key/value хранилищах, типа memcachedb или apc. Тогда DB для выборки фоток будет использоваться гораздо реже.

Во-первых не предложили
легко... имеем например id 12345 берем последние 2, 3 или 4 цифры в зависимости от того сколько нужно папок и все загружаем в папку 45 файл с именем 12345.jpg
1) заполнение папок равномерно
2) нет дополнительного поля для хранения имени и пути к файлу
3) нет вообще никаких вычислений уникального имени файла
4) чаще всего id_user хранится в сессии, и подключить аватар на любой странице
можно просто... 45/12345.jpg без каких либо обращений к базе данных
5) если это форум, то id_user есть в каждом сообщении, аватарку прикрутить не составляет труда
6) для подключения в готовом проекте требуется минимум кода
___
называйте минусы моего варианта.

>> называйте минусы моего варианта.

Дано: у пользователя может быть более одной аватары. Задача: вывести все аватары пользователя.

Как будете решать без обращения к БД?

ну во первых, такой задачи не было, а во вторых совсем без обращения к БД даже тот вариант который выше не обходится, я говорил что id_user чаще всего присутствует в сессии что с аватарками, что без аватарок и лишний раз запрос к базе просто не нужен.
Если нужно более одной аватарки на аккаунт, то нет проблем
нужно всего-лишь добавить таблицу id_avatar | id_user
тут можно еще интереснее придумать распределение по папкам...
но (жирными буквами) опять таки никакого "изобретения" формирования имени файла все равно не нужно
ваш вариант (лично для меня) применим только если не используется база данных

>> нужно всего-лишь добавить таблицу id_avatar | id_user

Чем это принципиально отличается от моего варианта? Или просто поспорить хочется на ровном месте?

>> тут можно еще интереснее придумать распределение по папкам..

Кто ж спорит. Я показал принцип.

>> никакого "изобретения" формирования имени файла все равно не нужно
>> можно еще интереснее придумать

Вы уж определитесь, а то неудобно как то :)

>> ваш вариант (лично для меня) применим только если не используется база данных

Круто. А как без БД ставить в соответствие файл и его владельца?

Вы уж определитесь, а то неудобно как то :)
вы издеваетесь? или я на столько тупой, что не могу подобрать понятные для вас слова?
вы имя файла формируете средствами РНР, я его просто беру из базы
это и есть принципиальное отличие от вашего варианта
если для вас в этом нет никакой разницы, если вы не видите разницы между формированием имени файла и имени папки, то разрешите откланяться
___
Круто. А как без БД ставить в соответствие файл и его владельца?
а это уже "контрольный" в голову :).... "пожалейте мои гланды"))

Простой вопрос разрешите? Какая самая большая система, которую Вы проектировали?

я не спроектировал ни одной системы, я не написал ни одного сайта, я вообще не программист...
(хотя мог бы сказать, что запрограммировал и гугл и яндекс и рамблер и яху вдоль и поперек)
вы полагаете я не имею права с вами спорить? и тем более учить вас уму разуму? :)
с удовольствием послушаю что написали вы и тем более то как вы собираетесь это доказать ;)
___
поверьте, когда заканчиваются аргументы.. не все средства хороши)

>> я не спроектировал ни одной системы, я не написал ни одного сайта, я вообще не программист...

Спасибо за честность.

:) я уже второй год пишу когда время есть игру морской бой... абсолютно некоммерческий проект для детей
тут первый вариант движка "на массивах", но привязка к сессии не устраивала, а гонять массив тупо туда сюда в БД просто глупо
на "новогодних каникулах" переписал все с использованием БД, абсолютно другой алгоритм получился

В первую очередь нужно еще раз подчеркнуть, что если файлов мало, то и париться с несколькими папками нечего. Если файлов много... то может так случиться, что их удаляются и добавляют жители нескольких стран в течение нескольких лет... Не знаю, как с изображениями, но есть базы, которым чисел в BIGINT не хватает и они переходят на строковые хэши. Разницы нет, суть одна и та же, взять строку (чтобы это не было строка или число) и выбрать символы. Однако, бывает так, что под изображения выделено 28 серверов (т.е. речь идет уже не о папках, а о железках, которые так просто до 100 не догонишь), нужно всех пользователей по ним распределять одновременно, вот с 10-чной системой исчисления это сделать сложнее, а с хэшами - только в путь. Фактически вам все равно в этой ситуации придется использовать хэши, даже если это будет 01 ... 28. Выглядеть это может как числа, но это строковый хэш, да и в вашем примере это тоже строковый хэш, только его неудобство, что у него основание 10 и распределять по серверам не кратным 10 сложнее (не смертельно, но все же).

но есть базы, которым чисел в BIGINT не хватает и они переходят на строковые хэши
когда это мы в теме успели отказаться от числового идентификатора строки?
да и по поводу баз которым "не хватает", вы лично уверены что там правильно организована архитектура БД раз возникла такая проблема? боюсь даже спросить про время запроса к таким БД... скорее всего измеряется в "парсеках" :)
нужно всех пользователей по ним распределять одновременно, вот с 10-чной системой исчисления это сделать сложнее, а с хэшами - только в путь
чем кратность 10 отличается от кратности 16? лично для меня ваши аргументы, при всем уважении к вам, неубедительны
да и заговорили вы о таких заоблачных проблемах лишь потому что других аргументов в нашем споре нет :)
___
все-таки я буду делать средствами СУБД то что можно ими сделать, а не перекладывать на "плечи" РНР (это и в вашей книге тоже написано :) ) ну а остальные пусть делают как хотят... я им не указ и не авторитет)

>да и по поводу баз которым "не хватает", вы лично уверены что там правильно организована
>архитектура БД раз возникла такая проблема? боюсь даже спросить про время запроса к таким
>БД... скорее всего измеряется в "парсеках" :)
Конечно, серьезные базы данных легко выбиваются за 2^64 и за один сервер. Просто большие базы данных не валяются на каждом углу, но наблюдения накапливаются за годы, десятилетия и их нужно хранить, одних галактик уже больше 2^64 насчитали, про звезды и планеты уже и речи не идет... да какой-нибудь порт или спутник-шпион генерирует информации столько, что только успевай кассеты менять. 2^64 это не такая большая величина, как кажется на первый взгляд. Да в веб такие базы используются редко - слишком много народу нужно обслуживать, сервер ляжет, по возможности используются небольшие базы.

>чем кратность 10 отличается от кратности 16? лично для меня ваши аргументы, при всем
>уважении к вам, неубедительны
> да и заговорили вы о таких заоблачных проблемах лишь потому что других аргументов в нашем
>споре нет :)
Во первых не 16, а 36. Во вторых аргументация есть, вы её просто не понимаете/принимаете. Проблема в том, что путь к файлу все-равно нужно хранить в строке и выводить на страницах, в больших системах, чем путь короче - тем лучше (экономится место, экономится трафик, экономится процессор). А теперь смотрите - это названия одного и того же файла в разных позиционных системах - чем больше символов вы задействуете на одном месте, тем короче.
4000000000000.jpg
1125899906842624.jpg
10000000000000000000000000000000000 0000000000000000.jpg

>все-таки я буду делать средствами СУБД то что можно ими сделать, а не перекладывать на
>"плечи" РНР (это и в вашей книге тоже написано :) ) ну а остальные пусть делают как хотят... я
>им не указ и не авторитет)
Пока задачи и базы маленькие разумеется и глупо поступать по другому. Будет несколько серверов, будете делать как пишем :)

чем больше символов вы задействуете на одном месте, тем короче
с этим я и не спорил (хотя выигрывая в длине, проигрываем в типе поля, со всеми вытекающими)
и это я как раз отлично понимаю
я про равномерное распределение на 28 (на 37, на 53, на 82) серверов в чем отличие 10-ной и 16-ной систем? каким боком тут кратность поможет?

К строке вы можете префикс от 01 до 28 добавить без проблем, потом появится сервера с 29 по 54 - просто изменится префикс, к числу вы этого уже не добавите, если вы до этого просто делили на 28 число, то с вводом новых серверов нельзя будет делить на 54, так как для вычисления позиции старых файлов вам нужно делить на 28. Это можно было бы избежать, если бы у вас был строковый хэш, но так как у вас числовой хэш - он увеличивается равномерно и суффикс или префикс в него уже не упакуешь.

И это мы еще пока не рассматриваем ситуацию, когда вам нужно MySQL сервер (и одну базу данных) расположить не на одном, а на десятке другом серверов. Есть преимущества в строковых хэшах... хотя бы еще потому, что они сравниваются сначала, а не с конца, поэтому их можно проиндексировать, в отличие от предложенной вами схемы: нельзя построить обратный индекс в MySQL, т.е. быстро выбрать все записи для чисел, заканчивающихся на 47. А когда вам нужно обслужить все записи одного сервера, это становится важным.

PS Если бы не было преимуществ - никто бы такие хэши не использовал бы, но их используют и довольно интенсивно. В MySQL, конечно, редко встречается, как правило, под MySQL разворачивают не очень большие базы, MyISAM на больших объемах захлебывается, а InnoDB не сильно шустрый и крайне своеобразный.

К строке вы можете префикс от 01 до 28 добавить без проблем
я и к числу могу добавить префикс без проблем, и точно так же буду знать что первые два три символа это префикс, с чего вы взяли что я собрался что-то на что-то делить? и почему вы считаете что делить можно только в десятичной системе? :) и уж абсолютно мне непонятно почему вы заняли позицию, что в десятичной системе нужно без вариантов делить? :)

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

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

>и уж абсолютно мне непонятно почему вы заняли позицию, что в десятичной системе нужно без
>вариантов делить? :)
Ну отнимайте, складывайте или умножайте... если это число, с ним не так много операций можно провернуть. Если это строка, читайте выше - есть более экономные способы работы со строками, чем больше символов используется в строке, тем более компактным способом можно передать больше информации.

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

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

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

>и уж абсолютно мне непонятно почему вы заняли позицию, что в десятичной системе нужно без
>вариантов делить? :)
Ну отнимайте, складывайте или умножайте... если это число, с ним не так много операций можно провернуть. Если это строка, читайте выше - есть более экономные способы работы со строками, чем больше символов используется в строке, тем более компактным способом можно передать больше информации.

Просто таким образом гораздо проще обеспечить равномерное распределение файлов по поддиректориям, особенно, на очень большом объёме фоток.

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

гораздо проще обеспечить равномерное распределение файлов
я бы не стал так утверждать... может быть тысячу df и только один de так как в формировании имени присутствует "элемент неожиданности"
пример равномерного распределения смотрите выше

[поправлено модератором]

"Каждый мнит себя стратегом, видя бой со стороны."

>я бы не стал так утверждать... может быть тысячу df и только один de так как в формировании имени присутствует "элемент неожиданности"
>пример равномерного распределения смотрите выше
Если будет делать человек впервые столкнувшийся с проблемой, возможно, но вообще задаче равномерного распределения 100 лет в обед, по ней стадо слонов прошлось и равномерное распределение давно уже обеспечивают. У людей десятки, сотни, тысячи серверов, на которых нужно хранить файлы, не уж то думаете у них одни серверах пашут, а другие простаивают... 10-ное основание не всегда возможно и удобно использовать, чаще используют строково-числовые хэши, когда вы выходите за границу числа двойной точности, вам волей не волей приходится использовать строки, хоть для чисел, хоть для строк - в этом случае строки выгоднее - они больше информации несут, чем числа, а следовательно занимают меньше места, т.е. имена файлов получаются компактнее и занимают меньше места.

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