«Камчатский форум» logo

Здравствуйте, гость ( Вход | Регистрация )

3 страниц  < 1 2 3 >   ( К первому непрочитанному сообщению )
Ответить · Открыть тему
> Работа с графикой в PHP
Screen
11.09.2007, 7:57
Сообщение #21


Заслуженный участник
*****

Награды: 3
Группа: ?????????
Сообщений: 991
Регистрация: 28.07.2005

Репутация: 8 [ - / + ]


Картинки можно хранить в БД.

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


--------------------
Торговый бот для крипто биржи: https://fond.btc2yandex.com/
Обмен Bitcoin: https://btc2yandex.com/
Офлайн · Карточка · Приват
^
Kevin
11.09.2007, 8:11
Сообщение #22


*******
*******

Награды: 9
Группа: ????. ??????
Сообщений: 3 738
Регистрация: 02.04.2004

Репутация: 42 [ - / + ]


Цитата(Screen @ 11.09.2007, 9:57)
Картинки можно хранить в БД.

ИМХО, хранить не_текст в БД --- глупость :-)

Сообщение отредактировал Kevin - 11.09.2007, 8:11
Офлайн · Карточка · Приват
^
Ilya V. Rudomilov
11.09.2007, 11:56
Сообщение #23


Путяра, пшёл вон!
*******

Награды: 9
Группа: ??????
Сообщений: 14 825
Регистрация: 30.03.2004

Репутация: 36 [ - / + ]


Цитата
Картинки можно хранить в БД.

Любители садомазохизма - да. Это возможно, но очень не рекомендуется - возникает слишком высокая нагрузка на БД и очень большой трафик между сервером БД и веб-сервером.
Цитата
ИМХО, хранить не_текст в БД --- глупость :-)

Согласен.

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

Все файлы нужно хранить в файликах. Превьюшки генерировать при каждом запросе ни в коем случае нельзя. Исключение можно сделать для очень малопосещаемых сайтов (до 50 хостов в сутки).


--------------------
Обязательно к изучению - мой блог о моей жизни в Чехии! И хватит спрашивать "Почему же Чехия?.." - все ответы описаны уже.
Офлайн · Карточка · Приват
^
Vetinary
11.09.2007, 16:44
Сообщение #24


Заслуженный участник
*****

Награды: 3
Группа: VIP
Сообщений: 818
Регистрация: 18.09.2004

Репутация: 20 [ - / + ]


Цитата(Kevin @ 11.09.2007, 1:11)
ИМХО, хранить не_текст в БД --- глупость :-)
наверное, именно поэтому создатели таких программных продуктов как Oracle, PostgreSQL, MySQL, MSSQL до сих пор оставляют поддержку хранения бинарных объектов в БД.
чёрт, надо им намекнуть, пожалуй, что дурью маятся... smile.gif


--------------------
"Коммерчески успешно принародно подыхать,
Об камни разбивать фотогеничное лицо,
Просить по-человечески, заглядывать в глаза
Добрым прохожим..."
© Янка, "Продано"

Mac OS X Hints — секреты Mac OS X
Офлайн · Карточка · Приват
^
Anger
11.09.2007, 17:04
Сообщение #25


***×***
*******

Награды: 4
Группа: VIP
Сообщений: 2 130
Регистрация: 05.04.2004

Репутация: 34 [ - / + ]


Цитата(Vetinary @ 11.09.2007, 18:44)
чёрт, надо им намекнуть, пожалуй, что дурью маятся... smile.gif

Раз уж бОльшая часть разумных программистов не видят в этом смысла, может само создание такой возможности имело чисто маркеинговый ход? Или веяние моды, а может быть сделано по принципу «лишь бы было» или «у конкурентов уже есть, а у нас нет» ^_^
А мы сидим и тупим, зачем это?


--------------------
Офлайн · Карточка · Приват
^
Kevin
11.09.2007, 17:14
Сообщение #26


*******
*******

Награды: 9
Группа: ????. ??????
Сообщений: 3 738
Регистрация: 02.04.2004

Репутация: 42 [ - / + ]


Vetinary, ключевое слово «хранение» :-)

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

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

Если что-то и можно сделать, то это автоматом не означает,
что это действительно правильно.

P.S.: Сам-то, поди, не хранишь бинарники в БД,
только вредничаешь попусту :-)

Сообщение отредактировал Kevin - 11.09.2007, 17:18
Офлайн · Карточка · Приват
^
Vetinary
11.09.2007, 18:04
Сообщение #27


Заслуженный участник
*****

Награды: 3
Группа: VIP
Сообщений: 818
Регистрация: 18.09.2004

Репутация: 20 [ - / + ]


Цитата(Anger @ 11.09.2007, 10:04)
может само создание такой возможности имело чисто маркеинговый ход? Или веяние моды, а может быть сделано по принципу «лишь бы было» или «у конкурентов уже есть, а у нас нет» ^_^
не думаю, что подобные варианты в данном случае имеют право на жизнь. когда важна скорость работы с данными и целостность их хранения вопросы "типа так модно" отметаются smile.gif
Цитата(Kevin @ 11.09.2007, 10:14)
Vetinary, ключевое слово «хранение» :-)
...........
Если что-то и можно сделать, то это автоматом не означает,
что это действительно правильно.
всё зависит от задачи. не web'ом единым сыт программист. в мире есть масса задач, и если в вебе тебе реализация хранения бинарников в БД не нужна (а кому-то может быть и это нужно), то есть масса других задач, где без подобной фичи очень и очень нелегко пришлось бы.
Цитата(Kevin @ 11.09.2007, 10:14)
P.S.: Сам-то, поди, не хранишь бинарники в БД, только вредничаешь попусту :-)
я не "вредничаю попусту". мой комментарий - всего лишь реакция на заявление "хранить не_текст в БД --- глупость :-)" (пусть даже с предшествующим "имхо") smile.gif


--------------------
"Коммерчески успешно принародно подыхать,
Об камни разбивать фотогеничное лицо,
Просить по-человечески, заглядывать в глаза
Добрым прохожим..."
© Янка, "Продано"

Mac OS X Hints — секреты Mac OS X
Офлайн · Карточка · Приват
^
Ilya V. Rudomilov
11.09.2007, 18:44
Сообщение #28


Путяра, пшёл вон!
*******

Награды: 9
Группа: ??????
Сообщений: 14 825
Регистрация: 30.03.2004

Репутация: 36 [ - / + ]


Цитата
наверное, именно поэтому создатели таких программных продуктов как Oracle, PostgreSQL, MySQL, MSSQL до сих пор оставляют поддержку хранения бинарных объектов в БД. чёрт, надо им намекнуть, пожалуй, что дурью маятся...

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

"Возможность хранения бинарников" - это не то же, что "хранение картинок в базе".


--------------------
Обязательно к изучению - мой блог о моей жизни в Чехии! И хватит спрашивать "Почему же Чехия?.." - все ответы описаны уже.
Офлайн · Карточка · Приват
^
Vetinary
11.09.2007, 18:50
Сообщение #29


Заслуженный участник
*****

Награды: 3
Группа: VIP
Сообщений: 818
Регистрация: 18.09.2004

Репутация: 20 [ - / + ]


Цитата(Ilya V. Rudomilov @ 11.09.2007, 11:44)
"Возможность хранения бинарников" - это не то же, что "хранение картинок в базе".
ещё раз повторю, мой комментарий, реакция на фразу Kevin'а "хранить не_текст в БД --- глупость". я так полагаю, не_текст - это не только картинки.


--------------------
"Коммерчески успешно принародно подыхать,
Об камни разбивать фотогеничное лицо,
Просить по-человечески, заглядывать в глаза
Добрым прохожим..."
© Янка, "Продано"

Mac OS X Hints — секреты Mac OS X
Офлайн · Карточка · Приват
^
Ilya V. Rudomilov
11.09.2007, 19:19
Сообщение #30


Путяра, пшёл вон!
*******

Награды: 9
Группа: ??????
Сообщений: 14 825
Регистрация: 30.03.2004

Репутация: 36 [ - / + ]


Цитата
ещё раз повторю, мой комментарий, реакция на фразу Kevin'а "хранить не_текст в БД --- глупость". я так полагаю, не_текст - это не только картинки.

Я согласен с Женей. Это - бред. Исключение составляют редкие случаи, когда для синхронизации иных способов нет. Подчеркиваю - синхронизации.

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


--------------------
Обязательно к изучению - мой блог о моей жизни в Чехии! И хватит спрашивать "Почему же Чехия?.." - все ответы описаны уже.
Офлайн · Карточка · Приват
^
L@mer
11.09.2007, 20:16
Сообщение #31


Ветеран
******

Награды: 3
Группа: ??????
Сообщений: 1 368
Регистрация: 25.11.2005

Репутация: 20 [ - / + ]


Любые структурированные данные выгоднее и удобнее хранить в БД. А то что не делают так, то это совсем другое. Или Вы серьезно считаете, что операции с файловой системой напрягают меньше. Может просто в таком убогом языке как PHP дико хранить двоичные данные в БД,

Сообщение отредактировал LСобакаmer - 11.09.2007, 20:46


--------------------
Я бы изменил мир, но бог не дал исходников...
Изображение
Офлайн · Карточка · Приват
^
Vetinary
11.09.2007, 21:24
Сообщение #32


Заслуженный участник
*****

Награды: 3
Группа: VIP
Сообщений: 818
Регистрация: 18.09.2004

Репутация: 20 [ - / + ]


Цитата(LСобакаmer @ 11.09.2007, 13:16)
Любые структурированные данные выгоднее и удобнее хранить в БД. А то что не делают так, то это совсем другое. Или Вы серьезно считаете, что операции с файловой системой напрягают меньше. Может просто в таком убогом языке как PHP дико хранить двоичные данные в БД,
не совсем мне понятно, каким боком принцип хранения данных и построения БД в принципе зависит от языка программирования, который с ней будет работать.
так или иначе, чтоб понятней было, я вам просто скажу, что дело не в пхп как таковом. просто в случае web удобно иметь front-end перед веб-сервером (скажем, nginx), который будет отдавать бинарные и текстовые статичные (стили, скрипты) данные минуя веб-сервер, что позволяет добиться очень хороших показателей производительности серверов при большой посещаемости. поэтому в случае с веб в контексте сервера apache удобнее держать картинки в FS дабы минимизировать затраты на создание процесса apache, интерпретацию php-скрипта, инициализацию соединения с БД, выборку (что равносильно чтению с диска) и дальнейшие операции (если необходимо - подготовку превьюшки) и вывод объекта пользователю. т.е. выигрыш в данном случае просто очевиден.
абстрагируясь же от задач веба и обращая взгляд на различные корпоративные приложения призваные давать доступ к огромному количеству данных (отчёты, архивы, медиа) большому количеству людей, быть защищёнными и целостными (сосредоточенными в одной базе и связанными индексами), реплицируемыми - тут налицо выигрыш хранения бинарных объектов в БД, потому как в противном случае получится такая каша, что я и врагу не пожелал бы в это лезть smile.gif

Сообщение отредактировал Vetinary - 11.09.2007, 21:25


--------------------
"Коммерчески успешно принародно подыхать,
Об камни разбивать фотогеничное лицо,
Просить по-человечески, заглядывать в глаза
Добрым прохожим..."
© Янка, "Продано"

Mac OS X Hints — секреты Mac OS X
Офлайн · Карточка · Приват
^
Ilya V. Rudomilov
11.09.2007, 22:19
Сообщение #33


Путяра, пшёл вон!
*******

Награды: 9
Группа: ??????
Сообщений: 14 825
Регистрация: 30.03.2004

Репутация: 36 [ - / + ]


В общем, цитирую одну из статей:
Цитата
Поля BLOB можно хранить либо в базе данных, либо в файловой системе. В последнем случае пути к объектам BLOB хранятся в базе данных. Хранение объектов BLOB в файловой системе потребует от вас чуть больше работы, зато позволит добиться гораздо более высокой производительности, чем при хранении их в базе данных.

С увеличением числа сохраняемых двоичных объектов производительность процессора базы данных быстро уменьшается. Кроме того, удаление таких объектов может привести к образованию в файлах базы данных большого числа "мертвых зон". Когда вся информация от и до проходит через процессор базы данных, ему труднее поддерживать многозадачный режим работы. Хранение объектов BLOB в файловой системе, напротив, облегчает создание ссылок на загружаемые из Web-страниц объекты. После загрузки информации Web-сервер обслуживает обращение к файлу, а процессор базы данных занимается в это время другими задачами. Дополнительным преимуществом также является и то, что администратор может легко каталогизировать и администрировать мультимедийные файлы, записанные на диск, а также делать их резервные копии.

Все просто и понятно.
Цитата
абстрагируясь же от задач веба

Вот именно, что абстрагируясь от веба. Я бы удавился, если на камфоруме картинки хранились в базе.

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

Цитата
выборку (что равносильно чтению с диска)

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


--------------------
Обязательно к изучению - мой блог о моей жизни в Чехии! И хватит спрашивать "Почему же Чехия?.." - все ответы описаны уже.
Офлайн · Карточка · Приват
^
psk
11.09.2007, 22:39
Сообщение #34


Заслуженный участник
*****

Награды: 4
Группа: ??????
Сообщений: 769
Регистрация: 09.11.2005

Репутация: 6 [ - / + ]


так. пора тему "резать".

Делаю так. Сохраняю по 100 файлов в папку. Имя папки - номер.
В БД для каждого фото поле id содержит auto_increment. С id от 1 до 100 фото хранится в папке 1, от 101 до 200 в папке 2 и т.д.
Имя файла будет генерироваться функцией time() + '.jpg' (для того, чтобы усложнить просмотр фотографий без скрипта). Перед записью проверка, есть ли уже такое имя фото (когда в одну секунду добавляется не одна запись). Если есть, к time() прибавляем 1.

Кстати, как получить перед записью в базу текущую позицию auto_increment?


--------------------
Господи правый, пошли нам прозрения час
Офлайн · Карточка · Приват
^
Vetinary
11.09.2007, 22:46
Сообщение #35


Заслуженный участник
*****

Награды: 3
Группа: VIP
Сообщений: 818
Регистрация: 18.09.2004

Репутация: 20 [ - / + ]


Цитата(Ilya V. Rudomilov @ 11.09.2007, 15:19)
В общем, цитирую одну из статей:
[.........]
Все просто и понятно.
а теперь озвучь, пожалуйста, о какой БД шла речь. или ты всех под одну гребёнку?

Цитата(Ilya V. Rudomilov @ 11.09.2007, 15:19)
Вот именно, что абстрагируясь от веба. Я бы удавился, если на камфоруме картинки хранились в базе.
скажи, где я говорил, что в проектах для веб надо картинки или ещё какие бинарники класть в БД?

Цитата(Ilya V. Rudomilov @ 11.09.2007, 15:19)
И даже внутри корпорации куда удобнее перемещать файлы, нежели все в БД. По крайней мере имхо.
вот именно, что имхо. ты можешь предположить любую задачу, которая возникает в той или иной компании? ты можешь однозначно сказать, что для любой из задач подойдёт хранение объектов в ФС, а хранение их в БД усложнит задачу и замедлит работу приложения? и это будет справедливо для любой БД?

Цитата(Ilya V. Rudomilov @ 11.09.2007, 15:19)
Да и лично я не видел ни одного крупного проекта, где бы файлы хранились в БД, и ни одного разработчика, который лестно отзывался о хранении изображений в БД.
"видишь суслика? а он есть" (с)
это что касается того, что ты не видел таких проектов. а про разработчиков - ты ведь со всеми общаться не мог, верно?

Цитата(Ilya V. Rudomilov @ 11.09.2007, 15:19)
Родион, не преувеличивай. С диска прочитается в разы быстрее, чем с БД.
Илья, я уж и не знаю, как тебе сказать, чтоб читал ты не наискосок, а по строчкам. smile.gif
когда происходит выборка из БД, данные читаются с диска. именно это я и имел ввиду при приведении алгоритма. я совсем не сравнивал скорость.


--------------------
"Коммерчески успешно принародно подыхать,
Об камни разбивать фотогеничное лицо,
Просить по-человечески, заглядывать в глаза
Добрым прохожим..."
© Янка, "Продано"

Mac OS X Hints — секреты Mac OS X
Офлайн · Карточка · Приват
^
Vetinary
11.09.2007, 23:01
Сообщение #36


Заслуженный участник
*****

Награды: 3
Группа: VIP
Сообщений: 818
Регистрация: 18.09.2004

Репутация: 20 [ - / + ]


Цитата(Paskam @ 11.09.2007, 15:39)
Делаю так. Сохраняю по 100 файлов в папку. Имя папки - номер.
В БД для каждого фото поле id содержит auto_increment. С id от 1 до 100 фото хранится в папке 1, от 101 до 200 в папке 2 и т.д.
Имя файла будет генерироваться функцией time() + '.jpg' (для того, чтобы усложнить просмотр фотографий без скрипта).
неверная, на мой взгляд, реализация. немасштабируемая.
100 - 199 -> 1/
200 - 299 -> 2/
.....................
100000 - 199999 -> ???

для себя вывел простое решение:
имя файла = md5(mktime() + какой-нить случайный фактор) + расширение;
предположим, получили строку 1a2b3c4d5ef.jpg
путь к файлу - путь_до_каталога/1/a/2/1a2b3c4d5ef.jpg
таки образом в базу можем класть строку "/1/a/2/1a2b3c4d5ef.jpg"
путь берётся, как можно заметить, из первых трёх символов получившегося имени файла. создаётся функцией с параметром длины пути. т.е. можно сделать его или короче или длиннее (если файловая система начнёт загибаться от количества файлов в одном каталоге). учитывая, что md5() возвращает строку из элементов 16-ричной системы исчисления, у нас получается весьма компактное хранилище с уровнем вложенности до 32 (а это ОООООчень много файлов)

таким образом сейчас хранится кэш запросов к БД и картинки на проектах, за которые я в ответе, так что принцип обкатан в бою smile.gif

P.S. ещё забыл указать, что если есть вероятность того, что соотношение изображений к одному объекту будет превышать 1x1 - лучше вынести их в отдельную таблицу по принципу "многие к одному"

Сообщение отредактировал Vetinary - 11.09.2007, 22:59


--------------------
"Коммерчески успешно принародно подыхать,
Об камни разбивать фотогеничное лицо,
Просить по-человечески, заглядывать в глаза
Добрым прохожим..."
© Янка, "Продано"

Mac OS X Hints — секреты Mac OS X
Офлайн · Карточка · Приват
^
L@mer
11.09.2007, 23:20
Сообщение #37


Ветеран
******

Награды: 3
Группа: ??????
Сообщений: 1 368
Регистрация: 25.11.2005

Репутация: 20 [ - / + ]


Понял так, что алгоритмы доступа и обработки данных реализованные в ФС, существенно лучше нежили в специализированном ПО (сервера БД)?
И так представим 50000 images с привью разных размеров и все это через ФС - жесть однако. Конечно ИМХО.

Сообщение отредактировал LСобакаmer - 11.09.2007, 23:21


--------------------
Я бы изменил мир, но бог не дал исходников...
Изображение
Офлайн · Карточка · Приват
^
psk
11.09.2007, 23:29
Сообщение #38


Заслуженный участник
*****

Награды: 4
Группа: ??????
Сообщений: 769
Регистрация: 09.11.2005

Репутация: 6 [ - / + ]


Цитата(Vetinary @ 12.09.2007, 1:01)

неверная, на мой взгляд, реализация. немасштабируемая.
100 - 199 -> 1/
200 - 299 -> 2/
.....................
100000 - 199999 -> ???

99900 - 100000 -> 999/
100000 - 100100 -> 1000/
100100 - 100200 -> 1001/

Чего-то я не понимаю?

Цитата
для себя вывел простое решение:
имя файла = md5(mktime() + какой-нить случайный фактор) + расширение;
предположим, получили строку 1a2b3c4d5ef.jpg
путь к файлу - путь_до_каталога/1/a/2/1a2b3c4d5ef.jpg
таки образом в базу можем класть строку "/1/a/2/1a2b3c4d5ef.jpg"
путь берётся, как можно заметить, из первых трёх символов получившегося имени файла. создаётся функцией с параметром длины пути. т.е. можно сделать его или короче или длиннее (если файловая система начнёт загибаться от количества файлов в одном каталоге). учитывая, что md5() возвращает строку из элементов 16-ричной системы исчисления, у нас получается весьма компактное хранилище с уровнем вложенности до 32 (а это ОООООчень много файлов)

таким образом сейчас хранится кэш запросов к БД и картинки на проектах, за которые я в ответе, так что принцип обкатан в бою smile.gif

Хотел иметь одно поле в таблице и для имени файла и для времени добавления фото.
Цитата
P.S. ещё забыл указать, что если есть вероятность того, что соотношение изображений к одному объекту будет превышать 1x1 - лучше вынести их в отдельную таблицу по принципу "многие к одному"

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


--------------------
Господи правый, пошли нам прозрения час
Офлайн · Карточка · Приват
^
Ilya V. Rudomilov
11.09.2007, 23:56
Сообщение #39


Путяра, пшёл вон!
*******

Награды: 9
Группа: ??????
Сообщений: 14 825
Регистрация: 30.03.2004

Репутация: 36 [ - / + ]


Цитата
Кстати, как получить перед записью в базу текущую позицию auto_increment?

Только после записи можно получить. Записал запись, mysql_insert_id() отдает тебе ID.
Цитата
а теперь озвучь, пожалуйста, о какой БД шла речь. или ты всех под одну гребёнку?

http://www.i2r.ru/static/480/out_11207.shtml Упоминается MySQL и PostgreSQL. Не думаю, что суть изменится.
Цитата
скажи, где я говорил, что в проектах для веб надо картинки или ещё какие бинарники класть в БД?

В первом же сообщении, http://www.kamforum.ru/index.php?s=&showto...ndpost&p=141859 , ты логически поставил под вопрос хранение автором темы картинок в файлах. Хотя теперь приближаешься к нашей с Жене точке зрения.

BLOB имеет право на существование, но это не панацея. Мы лишь об этом говорим.
Цитата
ты можешь предположить любую задачу, которая возникает в той или иной компании? ты можешь однозначно сказать, что для любой из задач подойдёт хранение объектов в ФС, а хранение их в БД усложнит задачу и замедлит работу приложения? и это будет справедливо для любой БД?

Применение тех или иных инструментов имеет значительный отпечаток "имхо" разработчика. Любые вещи можно делать разными вещами. Абсолютно верных решений нет.

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

Возможно и есть, я не отрицаю. Я же сказал, что среди известных мне таких нет.

Повторюсь - каждый человек делает так, как удобнее на его взгляд. Хранить в БД - удобнее для разработчика. Хранить в файлах - быстрее. Но ведь в первую очередь не для разработчика система делается. Так что если ему что-то неудобно, но это может привнести повышение производительности - пускай уж делает.
Цитата
когда происходит выборка из БД, данные читаются с диска. именно это я и имел ввиду при приведении алгоритма. я совсем не сравнивал скорость.

Да все хранится на дисках. smile.gif Скорость чтения просто разная.
Цитата
неверная, на мой взгляд, реализация. немасштабируемая.

Он не делает ничего гигантского, так что ему вполне хватит. И он легче разберется в куче своих файлов. Он ведь не будет писать целую систему по полному управлению файлами. Имхо - не забивай человеку мозг. smile.gif
Цитата
имя файла = md5(mktime() + какой-нить случайный фактор) + расширение;

В который раз это вижу. Как стандарт уже прям. smile.gif
Цитата
таким образом сейчас хранится кэш запросов к БД и картинки на проектах, за которые я в ответе, так что принцип обкатан в бою

Я на больших вещах тоже так делаю (если файлов очень много). Особенно удобно в случае чего файл вручную найти.
Цитата
P.S. ещё забыл указать, что если есть вероятность того, что соотношение изображений к одному объекту будет превышать 1x1 - лучше вынести их в отдельную таблицу по принципу "многие к одному"

Ибо сущность-связь. beer.gif Да и просто логически так проще. Хотя кто-то через разделитель в одном поле указывает - имхо, это убожество.


--------------------
Обязательно к изучению - мой блог о моей жизни в Чехии! И хватит спрашивать "Почему же Чехия?.." - все ответы описаны уже.
Офлайн · Карточка · Приват
^
psk
12.09.2007, 0:15
Сообщение #40


Заслуженный участник
*****

Награды: 4
Группа: ??????
Сообщений: 769
Регистрация: 09.11.2005

Репутация: 6 [ - / + ]


Цитата(Ilya V. Rudomilov @ 12.09.2007, 1:56)
Только после записи можно получить. Записал запись, mysql_insert_id() отдает тебе ID.

ага. спасибо. в принципе все равно, до или после.
А как его вручную изменить?

Цитата
Он не делает ничего гигантского, так что ему вполне хватит. И он легче разберется в куче своих файлов. Он ведь не будет писать целую систему по полному управлению файлами. Имхо - не забивай человеку мозг. smile.gif

IMHO - Vetinary, забивай...

Сообщение отредактировал Paskam - 12.09.2007, 0:20


--------------------
Господи правый, пошли нам прозрения час
Офлайн · Карточка · Приват
^

3 страниц  < 1 2 3 >
Ответить · Открыть тему
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 



Код кнопки 88x31 Текстовая версия Русская версия Invision Power Board v2.1.7 © 2006  IPS, Inc.