Форум MySQL

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

Если имя формируется по имени большого изображения, то к чему это имя держать в базе?

Если так, то да, Вы правы, но я забыл сказать, что имя большого изображения будет формироваться таким образом

<?php  $ext = // получаем расширение файла  $big = date("YmdHis", time()).$ext; ?>

Тогда в этом случае надо будет создавать дополнительные поля в таблице.
Запутался совсем....
Дело в том, что в старом варианте, который надо переделать, очень хитро формируется имя большой фотографии. В таблицу заностится, кроме названий фото, ещё и текстовая информация, после записи текстовой информации, через "SELECT MAX(id+1)..." начинается формироваться имя большой фото, а затем уже превью...
Даже не так, сначала через (максимальный айди + 1) имя фотографии, а уж потом всё это, вместе с текстовой информацией заносится в базу
По моему бред полнейший.

>Даже не так, сначала через (максимальный айди + 1) имя фотографии,

Вот это действительно жуть.
Потому что если хочется иметь гарантированный результат, никакие (максимальный айди + 1) использовать нельзя.
Сперва получить строку и её id и лишь потом применять этот id где-то еще.
Иначе есть шанс - в данном случае - потереть параллельно загружаемую фотографию.

>Иначе есть шанс - в данном случае - потереть параллельно загружаемую фотографию

И головная боль, пока разберёшься куда и что идёт :):):)

Вы думаете, что механизм формирования имени определяет условие помещения в базу имени "копии", которому просто добавляется префикс? Это с чего такое утверждение?
Выбросите всю эту хрень "SELECT MAX(id+1)... даже не так, сначала через (максимальный айди + 1)", вполне хватит привязки ко времени и сессии.

Я ни чего не утверждаю, просто спрашиваю как будет всё таки лучше, получать из базы уже готовое имя копии или формировать его при выводе в браузер?
А по поводу "SELECT MAX(id+1)... даже не так, сначала через (максимальный айди + 1)", выбросил сразу же.

Если имя большого изображения as.jpg, а малого s_as.jpg, то есть ли смысл для него держать поле в таблице?

нет

понял, что не стоит.
вопрос по формированию имени при помощи date();
Если второй параметр не указан, то он по умолчанию равен значению time(), значит, достаточно указать просто date("YmdHis") при формировании имени изображения?

Я бы не стал только по дате/времени формировать имена, ибо в соседней сессии в это же самое время может записывать файл еще один пользователь, а значит...?

эт что. А если тот же пользователь в соседнем экране тоже файл записывает? :)
Проиготовил кучку форм, а потом прошелся мышью по [Submit]-кнопкам.
И всё. И крышка празднику.

Так что идея вообще отказаться от autoincrement как от источника данных для генератора имен - не самая здравая.

Так речь не идет об использовании autoincrement для формирования имени, этот абсурд автор уже выбросил, речь о времени/дате для него, и чисто этот параметр использовать... ну это как повезет, если еще повезет. )

>Так речь не идет об использовании autoincrement для формирования имени, этот абсурд автор уже выбросил,

Я о том и говорю, что абсурдом является не использование autoincrement - это как раз вполне здравый подход, а выполнение над полученным id арифметических операций, выводящих значение за рамки области определения реального времени.
в том и суть, что время/дата хоть и редко, но могут дать коллизию.
Автоинкремент её не даст по определению. Если результат не начать ковырять.

Не надо никаких дерганий базы ради получения id для имени - время + сессия, думаю, вполне достаточно.

>в том и суть, что время/дата хоть и редко, но могут дать коллизию....

sim5 писал выше, что можно использовать привязку к дате/времени + сессия. по идее это

<?php  $exp = // получаем расширение файла $name = date("YmdHis", time()).session_id().$exp;

вообще ни когда не вызовет ни каких проблем. или всё таки может?

У вас когда либо были проблемы со сессиями, так чтобы разным пользователям вдруг был дан один и тот же идентификатор сессии?

пока с таким не встречался, разве что на локальном и с одного браузера...
но и session_id() в чистом виде я думаю не стоит в имя вносить, может обрабатывать md5() ?
или бред я придумал?

Это у вас глюк локального сервера может быть, с таким встречался, хотя не одно и тоже имя, а постоянно одна и та же сессия. Если md5, то для даты/времени + сессия, а иначе какой смысл?

как я Вас понял, можно сначала занести текстовую информацию в базу, потом получить id этой записи и использовать его в имени изображения?
не слишком ли это будет морочительно и правильно ли я Вас понял?

я вообще хрен чё понимаю в "этом зоопарке"
книжки читает кто-нибудь?
1)вставить в базу инфу о фотке
2) сохранить фотку и привюшку на диске используя ласт_инсерт_ай-ди

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

>сохранить фотку и привюшку на диске используя ласт_инсерт_ай-ди

А потом еще раз к базе обращение... 1)вставить в базу инфу о фотке - имени то еще нет.

имя - это и есть id (!)

инфа о фотке - это категория, размеры, формат, и тд

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

Прежде чем поместить этот ID, его нужно еще сформировать и получить.
Поэтому имено так - второе обращение к базе.
И чем ваше айди лучше того, что я предложил?

Прежде чем поместить этот ID, его нужно еще сформировать
- встречайте буквально только что добавили в субд autoincrement
и получить
- ещё одна сверхновая функция last_insert_id()
Поэтому имено так - второе обращение к базе.
НЕТ
И чем ваше айди лучше того, что я предложил?
- 100% гарантия уникальности имени.
- id - это всегда цыфры, в отличии от хеша
- выборка по INT шустрее чем по VARCHAR
- как я уже говорил отпадает необходимость хранить это дополнительное ненужное поле (VARCHAR)
- не нужно изобретать велосипед и тратить ресурсы php на формирование имени... за Вас это сделает надежнее быстрее и лучше Система Управления Реляционной Базой Данных
___
кстати в инфе о фотке можно хранить название фотки которое дает пользователь, но на диск сохранять именно под именем id + соответствующие префиксы (если нужно)

Valick ну че херню то пороть, а?
Значит так: autoincrement, это тоже не панацея, а конечное все таки число, так что о 100% уникальности не говорите, уж если на то пошло.
Не думаю, что придется шастать по базе в поисках имени изображения, все таки в записях не оно главное.
Ну и так далее об остальном, как следствии этого....

PS. Кстати, ваше айди-имя имеет одну очень неприятную уязвимость.

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

Кстати, ваше айди-имя имеет одну очень неприятную уязвимость.
а вслух сказать? или это секрет?

Я не вижу и от вас весомых аргуметов, окромя как вывести жирным шрифтом известное. Зачем кричать?
Ваш метод, может быть и красив, но ваши имена, это не обязательно стройность от M до N. В этом ряду могут быть дыры, а значит, что при переезде тыблицы на новое место жительства полетит к чертовой матери вся ваша айдишная фамилия. Да и не только при преезде, просто обновить таблицу это уже проблема будет, и опять из-за дыр.
Аргуметы я вам привел - не является атоинкремент уникальным, эта уникальность имеет конечное значение.
Ваш довод по поводу - лучше искать номер нежели хэш крайне надуман, такое возможно только в специфических задачах, ну в этом случае и подход иной должен быть.

В общем я не вижу лучшего в использовании id. Впрочем я ведь не утверждал, что то, что я говорил, это лучшее из лучших, как это вы заявляете. Я лишь могу утверждать, что этот способ обеспечит уникальность имени. Именно это и нужно, и такое имя помещенное в таблицу не приносит никаких проблем, кроме надуманных.

Зачем кричать?
не кричать, а обратить внимание

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

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

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

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

В общем я не вижу лучшего в использовании id.
Не видите или не хотите видеть? В общем аргументов я вам привел достаточно, имеющий глаза да прочитает.

Спасибо, но я знаю о выделенном вами.

>полный бред, дыры ни чем не отличаются от форменного беспорядка (в Вашем случае)
>id - уникально и проиндексировано, это главное
>переезд на новое место тут совсем не при чем

Это в чем же беспорядок?! Имя уникальное, независомое от ID. А вот в вашем случае, при переносе таблицы с дырками (только не надо прикидываться, будто вы не знаете о чем речь), запись бывшая, например, под номером 15, на новом месте может получить номер 8, а следовательно и дите-картинку атоматом за номером 8, правда если такая еще будет. В общем это уже забота в вашем красивом подходе.

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

>запись бывшая, например, под номером 15, на новом месте может получить номер 8,

C какого, простите, перепугу?
кто-то будет значения первичного ключа выскребать из всего дампа?

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

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

Ограничение это обычно не достигается в течение жизни проекта, а если проект предусматривает такое достижение, в нем предусматривают процедуры сжатия таблиц и их ключей. И совершенно очевидно - предусмотрят и переименование связанных по ключам объектов.

Зачем выскребать, простой случай, когда есть часть удаленных записей, и простой перенос, когда на новом месте записи получат порядковые номера с 1 по n.... Я ведь не говорю о дубликате.

А кто сказал, что id записи, это имя файла, и это есть классика? Эта классика все таки имеет привязку, по неволе, а зачем она?

>Зачем выскребать, простой случай, когда есть часть удаленных записей, и простой перенос, когда на новом месте записи получат порядковые номера с 1 по n.... Я ведь не говорю о дубликате.

Так при простом переносе на исходном сервере экспортируют дамп.
А на целевом - импортируют этот дамп.
И записи вынуждены оказаться созданными один в один. Да иначе вся ссылочная целостность разлетится к...

Ну а сложный перенос, это, наверное, импорт + сжатие?


>А кто сказал, что id записи, это имя файла, и это есть классика? Эта классика все таки имеет привязку, по неволе, а зачем она?

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

Sic! MD5 - как и любая другая другая функция криптографического преобразования - функция тяжелая. Очень.

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

Я не прделагал md5, этого хотел автор.

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

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

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

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

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

По поводу - ваше удобнее, так заради бога, но для себя.

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

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

По поводу - ваше удобнее, так заради бога, но для себя.
Как так? мой подход для меня, а ваш для всех? Нет уж дудки :)

А кто говорил, что строки пропадают? Речь и дет о получении новых номеров этими строками, а не об их пропаже.

Я своего подхода не рекомендую никому как обязательное, но и не говорю, что он лучший, в отличии от вас. Подход по id, не удобен, ибо он привязан пожизненно к некоемому номеру изначально. Для меня точно. А уж вы как хотите.

Речь и дет о получении новых номеров
я как раз о том же
ЭТОГО БЫТЬ НЕ ДОЛЖНО
(вот теперь я кричу)
расстрелл деревянными пулями Вам ни о чем не говорит?

>ЭТОГО БЫТЬ НЕ ДОЛЖНО

Не зарекайтесь, жизнь гораздо сложнее, нежели мы ее себе представляем.
Все, я устал от пустой болтовни.

а я как раз устал доказывая очевидное

Подход по id, не удобен, ибо он привязан пожизненно к некоемому номеру изначально
чем привязка по номеру отличается от привязки по хешу?

Имени "Вася" пофигу под каким номером оно записано, и это как раз отсутствие привязки.

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

А при чем тут это? Valick хватит флудить, вы уже не в ту сторону и не о том.

я как раз в ту сторону и как раз о том
Вы сказали пофигу (не обосновывая), я сказал не пофигу (и обосновал это)
Так кто из нас флудит? Все что я сказал в самом начале можете считать константой...
а вот Вы по прежнему утверждаете, что мне нужен дополнительный запрос чтобы узнать id только что вставленной записи?
Ваши слова:
Прежде чем поместить этот ID, его нужно еще сформировать и получить.
Поэтому имено так - второе обращение к базе.
много писать не нужно.. (да - и я абсолютно уверен в своей правоте/ нет - я был не прав)

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

-

Какая связь? Еще раз повторяю - файлу на диске с "независимым" именем все равно под каким номером он записан в базе. А вот файлу с именем 20, который привязан к записи под номером 20 нет, не все равно. Вот именно это я и говорил. А о куче записей..., о том, что файлов с таким именем может быть много..., это уже ваше, и не понятно к чему, и для чего.
Помилуйте, от куда много? Но даже и если отвлечься от этого, то файлу все равно пофигу, под чем его там записали.
И какого покаяния вы от меня ждете?

второе обращение к базе - ДА, для того что бы получить ID.
И всё таки, Вы не ответили, раз Вы утверждаете, что "- выборка по INT шустрее чем по VARCHAR",
то где Вы будете хранить расширение файла, потому что, к примеру, 235ю.jpg уже далеко не INT, а пользователь может грузить и jpg и jpeg и gif...

расширение хранить в отдельном поле, и не только для того чтобы названия сортировать по INT это еще поможет и в дальнейшем при запросах с группировкой.
второе обращение к базе - ДА, для того что бы получить ID.
я скоро начну ругаться матом... если Вы не в силах понять это - то просто поверьте.
второго обращения к базе не нужно (!!!!!!!!!!!!!!!!) более того - это обращение даже преступно, так как вы можете схватить уже не свой а совершенно чужой id
SELECT MAX(id+1) это та же ошибка что и SELECT MAX(id)

Вы читать умеете?!
SELECT MAX(id+1) это та же ошибка что и SELECT MAX(id) это старый вариант, мне надо это переделать и изначально делал не я!
Вы пытаетесь записать информацию в базу, при этом Вам надо добавить изображение. Как Вы собираетесь использовать id записи в имени изображения не получив его из базы?

Как Вы собираетесь использовать id записи в имени изображения не получив его из базы?
говорю как шахерезада в 1001 раз
last_insert_id()
last_insert_id()
last_insert_id()
last_insert_id()
last_insert_id()
last_insert_id()
last_insert_id()
last_insert_id()
last_insert_id()
last_insert_id()
___
Хеопс, огромная просьба сделать выделение красным цветом :)

да-а-а-а-а , читаете Вы явно с трудом....
Покажите, пожалуйста, пример использования last_insert_id().

mysql_insert_id()

всего лишь вид сбоку

я в курсе как можно получить id последней записи, дело не в этом.
Если, как утверждает Valick, при использовании last_insert_id() можно получить id последней записи в таблице, но какой записи?
Зачем мне в имени изображения id отфонарной записи, не лучше ли что бы id записи и имя изображения совпадали?
А что бы получить id нужной записи, как Вы писали, то нужно обратиться к таблице и получить его, всё правильно.
А то, что Valick до хрипоты в голосе кричит об использовании last_insert_id(), так это его проблемы.

Утверждать, что Valick кричит до хрипоты можно было бы только, если бы это был видео форум. Не заметно за ним этого.) Просто это доводы в свою пользу с одной стороны. Давайте рассмотрим подробнее.
Именование по номеру автоинкрементом проще, но удобнее ли, и в конечном итоге проще ли? Из этого метода следует одно обязательное условие - нельзя ни в коем случае изменять этот номер, иначе.... Но ведь этот номер не всегда прогугленный параметр, а значит не обязательно на него накладывается табу, да и все может быть. Лично я единожды обжегся на таком именовании файлов, и зарекся на всегда. Но это еще не самое плохое - учытывать такую жесткую привязку файлов, есть более неприятный момент. Рассмотрим механизм загрузки файлов на сервер в этом случае:

1. Грузим файл и описания к нему, ну или иную сопутствующую ему информацию.
2. Работаем над ошибками.
3. Если информация нами принята, пишем ее в базу.
4. Получаем ID записи.
5. Именуем по ID файл и сохраняем его на диск.

Вот тут и начинается неприятное. Такой механизм может только подразумевать, что под некой ID записи возможно существует одноименный файл. А если не существует? Если при записи на диск произошла ошибка? Следовательно, при выводе записи нужно будет проверять наличие файла - информации о нем ведь не существует в базе (это один из аргументов оппонируемой стороны - нет необходимости держать данные в базе о имени файла). Ладно бы это одно изображение, а если речь идет о галерее? Можно представить сколько придется делать проверок файловых, чтобы знать - выводить или не выводить тег IMG.

Именуем файлы иным способом, формируя имя при получении и помещении его в последствии в базу для соответствующей ID:

1. Грузим файл и описания.
2. Если файл загружен, формируем о нем все необходимые для записи в базу данные, включая и имя его. Все эти данные, а также само тело файла сохраняем в сессии.
3. Проверяем ошибки ввода данных. Работаем над ошибками.
4. Если ошибок нет, записываем файл на диск из сессии.
5. Если файл записан успешно, то записываем в базу всю инофрмацию, а также имя изображения (и другую информацию о нем, если нужно). Если произошла ошибка записи файла, значит информации о файле записано не будет (возможны и вариации, как-то изучение ошибок и повтор записи).

Надо ли объяснять, что в этом случае не требуется проверок наличия файла на диске. А отсутствие жесткой привязки имени файла к ID записи позволяет править базу (при необходимости) как угодно, при этом путаницы с именами не произойдет, да и головной боли не будет от беспокойства по этому поводу.

Как вам поступить, решайте сами.

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

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

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

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

Вот тут и начинается неприятное. Такой механизм может только подразумевать, что под некой ID записи возможно существует одноименный файл. А если не существует? Если при записи на диск произошла ошибка?
у меня тоже нет проблем с проверкой записи файла на диск и если что очередной записью до тех пор пока результат не будет успешным, либо удаление записи из базы.
Сами Вы не в тот огород, причем изначально. Вся ваша логика основывается на вымышленных "персонажах".

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

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

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

ваши аргументы в использовании ID, его простоте и выгодности просто теряют всякий смысл
лично для Вас может и теряют
а лично для меня Ваш вариант изначально лишён смысла
____
Дмитрий вот совсем с Вами не спорит, потому что не раз зарекался, а я еще пытаюсь до Вас достучаться

Вот ваша "железная" логика:

1. Записали
2. Получили ID.
3. Усердно пытаемся записать файл.... не получилось, тогда
4. Удаляем запись

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

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

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

****

А причем тут Дмитрий? Он положения не исправит, ваш механизм неудачный не потому, что Дмитрий спорить не хочет.

Вам я не говорю того же самого. Чтобы записать дополнительное о файле в вашем случае, сперва надо записать, а потом получить и еще обновить....
только запись... ничего получать и обновлять не нужно, но вы вправе фантазировать сколь угодно долго.
Нет никакой выгоды в использовании ID, а тем более не стоит называть это легким решением, оно грешит недостатками, если внимательно рассмотреть его. Я уже обжегся на этой легкости, чего и вам желаю, если вы не способны так понять этого
обожглись Вы скорее всего по другой причине, и я даже подозреваю по какой (кстати у Вас много книг по MySQL?) и использование id тут ни при чем.
А причем тут Дмитрий?
а при том что Вы намеренно не хотите видеть и понимать то о чем он пишет

Ну да, логика более чем странная. Сперва экономиния на одном поле VARCHAR (это ваше, не мое, чтобы опять не говорили в мой адрес), потом оказывается грузим все таки (на авось в вашем методе) все сопутствующее об изображении в базу (странно, а почему бы имя файла тогда и не записать, по все тем же соображениям экономии?). Записали, а теперь игра на удачу - не получилось что-то, удалили.
Вы мне веские аргументы можете представить, где же выгода в вашем случае? И не ссылайтесь на Дмитрия, именно вы выдвигаете кучу аргументов, и среди них я не вижу ни одного, которое бы имело плюс огромный. Логичнее сохранять запись, даже при неудачной загрузке изображения, которое в последствии можно и добавить. Ваш "железный" метод этого не позволяет, кроме как удалить запись.

Зачем же догадываться почему я обжегся, причину я описывал выше.

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

Вам оно нужно знать о моих литературных предпочтениях, что я читаю и сколько? Можно всю литературу перечитать, но так и остаться неучем. Разве в этом дело?

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

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

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

Ну да, теперь это уже только идея? Valick, вы даже жирным выделяли где мне почерпнуть достоинства, и об экономии VARCHAR, это ваше, и экономия эта, это ради одного имени была... и т.п., и т.д... Перчитайте сами свои доводы, а потом уже обвиняйте меня в выдумывании чего-то.

я прекрасно помню все свои доводы

- как я уже говорил отпадает необходимость хранить это дополнительное ненужное поле (VARCHAR)

ключевое слово здесь ненужное

Вот именно - ненужное, по вашему, в чем и есть главный недостаток. Экономия на одном поле VARCHAR? И что она вам дает? Ради экономии вы теряете многое.
Я приводил свои доводы почему я отказался от такого именования файлов. Говорил почему неудобен это способ (ваш метод). Собственно об этом и спорить то долго не надо, достаточно все ЕСЛИ расставить и будет видно, чем страдает он. Я эти если приводил.
Я даже могу ожидать, что вы наведете "косметику" на свою идею, и предложите решиние выше указанных проблем уже в вашем методе. Могу ответить сразу - конечно можно решить, но ценой дополнительных усилий и расточительных, а в некоторых случаях и с излишеством, так как могут возникать неоднозначности.
Valick, я уже говорил, я обжегся единожды, и после этого хорошо подумал над всеми ЕСЛИ, чего и вам желаю. Может тогда вам станет очевидной "кажущая" легкость и удобство вашего метода (бог с ним, пусть идеи).
Лично я сейчас делаю так, как вкратце описал выше, и ваш метод даже врагу не пожелаю, накушался им, досыта. ;-)

Ну я говорил о last_insert_id() как о сущности, конечно же я ошибся и имел ввиду mysql_insert_id()

>я в курсе как можно получить id последней записи, дело не в этом.
>Если, как утверждает Valick, при использовании last_insert_id() можно получить id последней записи в таблице, но какой записи?
>Зачем мне в имени изображения id отфонарной записи, не лучше ли что бы id записи и имя изображения совпадали?

вообще-то LAST_INSERT_ID() и mysql_insert_id() возвращают ключ только что добавленной записи.
Последняя она или нет - несущественно.
Так что отфонарной такая запись всяко не будет.


>А что бы получить id нужной записи, как Вы писали, то нужно обратиться к таблице и получить его, всё правильно.

а вот это есть чушь.
Каким таким образом обратиться?

Вы правы, посмотрел в руководстве, сделал пару примеров для наглядности.
Плучилось, что этот вариант мне не подходит.
Что бы получить id нужны два запроса, первый - добавить запись, потом записать имя с этим id.
Вот из чего я исходил

<?php  error_reporting(E_ALL);  require_once("connect.php");  $query = "INSERT INTO `newusers`(`name`,`pass`) VALUES('TEST2','33333')";  if(mysql_query($query)){  $query = "INSERT INTO `newusers`(`name`,`pass`) VALUES('TEST2',LAST_INSERT_ID())";  mysql_query($query);   echo "<br> mysql_insert_id - ".mysql_insert_id();  }  else{   echo mysql_error();  } ?>

может я что то не так понял? Но если записать просто

<?php  $query = "INSERT INTO `newusers`(`name`,`pass`) VALUES('TEST2',LAST_INSERT_ID())";  mysql_query($query); ?>

будет записан "0" в поле pass.

вообще-то LAST_INSERT_ID() и mysql_insert_id() возвращают ключ только что добавленной записи.

Это я понял.

>расширение хранить в отдельном поле, и не только для того чтобы названия сортировать по INT >это еще поможет и в дальнейшем при запросах с группировкой.
Опять же, создвать отдельное поле в базе.... потом, при выборке из базы надо будет сводить значения двух полей. А не проще ли сразу записать имя изображения с расширением и не создавать отдельного поля в таблице?

А не проще ли сразу записать имя изображения с расширением и не создавать отдельного поля в таблице?
нет не проще

Проще и выгоднее!

не проще и не выгоднее
при одном поле содержащем например sim5.jpg и valick.png
составьте запрос для подсчета количества файлов разных форматов.

Не бросайтесь в крайности, Valick - уж если я не отказываюсь хранить имя файла в базе, то думаю вы понимаете, что для таких вещей как галерея, я уж точно догадаюсь хранить тип файла в отдельном поле. Не надо принимать меня за упрямого идиота. ;-)

Не переживайте, успокойтесь, книжки читают здесь :):):)
Ваша фраза " .....используя ласт_инсерт_ай-ди"
Моя фраза "...получить id этой записи...."
смысл то один и тот же, получений id записи, так зачем возмущаться?

Не переживайте, успокойтесь, книжки читают здесь :):):)
"Унесенные с ветром"? :))
Ваша фраза " .....используя ласт_инсерт_ай-ди"
Моя фраза "...получить id этой записи...."
отличия сами найдетё или подсказать? :)

хотелось прочитать Вашу версию

получить id можно по-разному, Вы не уточнили каким образом, а следовательно не сказали ровным счетом ничего.
Даже если закрыть глаза на то, что выше по тексту речь шла о SELECT
___
вообще странно, что тема так разрослась (а по идее и вообще не должна была появляться)
как сказал sim5, мне приходиться писать очевидное, да еще и доказывать это очевидное.

Да , тема разрослась, не ожидал....
> Даже если закрыть глаза на то, что выше по тексту речь шла о SELECT

Вот Вы и закрыли глаза :), речь шла о SELECT, но это в старом варианте, который мне надо переделать, а если я не уточнил, как я собираюсь получать id, то это не значит, что я не знаю о last_insert_id().

Сейчас,в старом варианте, имя изображения формируется с помощью "SELECT MAX(id+1)", затем приписывается префикс, например, "f" если это логотим фирмы и "frm" если это фото продукции фирмы. После этого запись заносится в базу. Получается, что если MAX id в базе "3", то имя фото будет f4.jpg, а id всей записи может быть и 201. Вот такая фигня.
При выборки из базы записей, что бы получить имя превью, надо приписать к имени фото ещё и "s", поучается что то вроде sf4.jpg
Я считаю, что это очень не удобно, поэтому и спрашивал какой вариан более приемлем.

Вы выше писали, что выборка по INT быстрее чем по VARCHAR, но если применять Ваш вариант, то при выборки из базы, надо ещё знать расширение файла, что бы приписать его к имени фото по id.

Получается, что пользователь может загрузить несколько изображений на сайт,

Формируйте уникальное имя картинки
id(юзера)_id(внесённого в БД инфо картинки).jpg(если расширение у всех одинаковое)
В Таблице поля INT
img

id_user     id_img(автоинкрементное)

вывод

<img src="/images/small_".$mr['id_user']."_".$mr['id_img'].".jpg" /> <img src="/images/big_".$mr['id_user']."_".$mr['id_img'].".jpg" />

либо создать 2 папки под картинки

/images/big/ /images/small/

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

Видать не совсем вам понятно.

Посмотрите на время которое затрачивает скрипт при ресайзе картинки и вопрос о времени как уникальном идентификаторе отпадёт сам собой :)

ну если совсем чтобы было в шоколаде то прописывайте в название картинки тайтл статьи, темы или что-то осмысленное +id картинки

>Посмотрите на время которое затрачивает скрипт при ресайзе картинки и вопрос о времени как уникальном идентификаторе отпадёт сам собой :)

Чего? Что, время по завершению этой операции уже не пригодное? Ну доводы, как у детей.