Не подскажете, как посмотреть идентификатор (id, primary key | auto_increment) для записи которую я вставляю?

Если ты говоришь о MySQL, то функцией last_insert_id()

именно о ней, спасибо

Да, но она работает так же как и mysql_insert_id(), тобишь показывает ид после запроса, а мне нужно узнать ид ДО того как я вставляю в базу данные =)

bE(o0L, без использования транзакций ты не должен это делать. да даже если используешь транзакции - не стоит так делать.

bE(o0L писал(а):

а мне нужно узнать ид ДО того как я вставляю в базу данные =)

Тебе это не нужно.

Да ладно, например phpMyAdmin показывает последний id (см. таблица -> операции).

даже Можно изменить последний id.
query="ALTER TABLE tablename PACK_KEYS = 0 CHECKSUM = 0 DELAY_KEY_WRITE = 0 AUTO_INCREMENT = YOUR_NEW_ID";

Цитата:

Может я не так выразился (до вставки данных в таблицу, мне _нужно_ знать с каким id запись туда пойдёт)

bE(o0L писал(а):

даже Можно изменить последний id

Вылизывать половички тоже можно. Но делать это вовсе не следует.

Простой вопрос: за какой надобностью тебе нужно знать id до вставки записи при использовании автоинкремента?

у меня к записи в базе привязано туча файлов, ябы хотел дать им имя как и ID, только вся работ с файлами идёт до запросов в базу (названия файлов также хранятся в базе).
Можно конечно делать два запроса -> первый добавит запись а второй узнаёт id, затем файл переименовать и сделать ещё один запрос на UPDATE

впринципе сейчас так и работает, но хотелось бы за раз всё делать.

Что мешает переименовать файл после вставки записи?

впринципе ничего, просто двойная работа

bE(o0L, перестрой логику работы. сначала пиши в базу, а потом в файл.

нужно не в файл, а имя файла как будущий id
Пожалуй будем в базу писать мнимые имена файлов, а потом переименовывать файлы.
Правда нецелесообразно и ресурсоёмко...

bE(o0L писал(а):

Пожалуй будем в базу писать мнимые имена файлов, а потом переименовывать файлы.

Что мнимого в таких именах?

Цитата:

Правда нецелесообразно и ресурсоёмко...

В чем ты видишь нецелесообразность и ресурсоемкость?

Цитата:

Что мнимого в таких именах?

по ним нельзя открыть файл. почему - см. выше

Цитата:

В чем ты видишь нецелесообразность и ресурсоемкость?

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


p.s.
в любом случае это уже не относится к топику. меня интересует - как узнать следующий id до записи в базу.

bE(o0L писал(а):

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

Что мешает сделать так: работа базы, запись файлов?

Цитата:

в любом случае это уже не относится к топику. меня интересует - как узнать следующий id до записи в базу.

Ответ очевиден: убрать автонумератор и создавать id самостоятельно.

bE(o0L, есть кардинальный способ - директивно задавать собственный unique id и пользоваться для твоих целей именно им. А корректного способа узнать следующий стандартный id нету. И вряд ли будет.

Тупой способ: найди максимальный ID и при вставке явно укажи на единицу больший.
Но это всё per rectum.
Сначала делаются проверки, а потом запись.
В таком раскладе запись файлов спокойненько размещается после записи в БД.

@TSV, узнать следующий id несложно. Но это требует лоченья базы. Как следствие -- резкое падение производительности.

Crazy,

Цитата:

Что мешает сделать так: работа базы, запись файлов?

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

Цитата:

Ответ очевиден: убрать автонумератор и создавать id самостоятельно.

в данном случае это не возможно

<sergio.ga> писал(а):

Тупой способ: найди максимальный ID и при вставке явно укажи на единицу больший.

Тоже только с обязательные лоченьем.

bE(o0L писал(а):

в данном случае это не возможно

Религия запрещает?

Crazy, дык там даже падением производительности можно не отделаться. Еще и клинчи придется ловить самостоятельно. Лоченье вообще лучше не рассматривать для верности.

bE(o0L, еще вариант - поставить дополнительное поле - флажок (bRecordIsValid), который не устанавливается до тех пор, пока запись не стала полностью корректна а имена файлов - "настоящими", то есть файлы существуют и в них нужное тебе содержимое.

bE(o0L, а вообще изменять/добавлять/удалять поля - можно? Или не дают?

@TSV,
производительность при варианте записи переименования (плюсь работа с самими файлами серверной программой) достаточно загружают сервер.

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

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

вроде можно -> add,select, insert,update,delete,create,drop table на базу

bE(o0L писал(а):

@TSV, производительность при варианте записи переименования (плюсь работа с самими файлами серверной программой) достаточно загружают сервер.

Сколь велика нагрузка на твой скрипт, если операция переименования файла оказывается значимой при оценке производительности? Больше 10000 обращений в минуту?

bE(o0L, сто пудов как (last_id+1). Но это не вполне корректно. За время пути собачка может подрасти, а last_id - может поменяться за время обработки.

Ыыы?? add,select, insert,update,delete,create,drop table Хммм...

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

Crazy, bE(o0L, ИМХО в таких случаях не нужно гадать про производительность, а нужно взять и померить.

это я не могу. к тому же суть не в этом. см топик

@TSV,


ээ всё что я делал из перечисленного - получалсь

Или я тебя не так понял?

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

проблема как раз существует, и решить её хочется малой кровью

bE(o0L, ты замерил производительность и нашел узкое место или просто фантазируешь?

bE(o0L, ты как раз пытаешься решить ее не малой кровью.