При добавлении новой записи в таблицу MySQL из Perl'а (через dbi:dbd) последняя добавляется не в конец таблицы, а где-нить посередине .Может добавляться всегда в одно и тоже место, смещая предыдущие записи вниз.
Перед добавлением постоянно деляется update полей последней записи. Может указатель в таблице стоит на одном и том-же месте? Но тогда как его смещать?
>При добавлении новой записи в таблицу MySQL из Perl'а (через dbi:dbd) последняя
>добавляется не в конец таблицы, а где-нить посередине.Не лезь в то как MySQL бинарно хранит данные для таблиц, он это делает правильно и оптимально :-) Вначале заполняются пустоты.
>>При добавлении новой записи в таблицу MySQL из Perl'а (через dbi:dbd) последняя
>>добавляется не в конец таблицы, а где-нить посередине.
>
>Не лезь в то как MySQL бинарно хранит данные для таблиц, он
>это делает правильно и оптимально :-) Вначале заполняются пустоты.В таблице нет никаких пустот :\
Записи добавляются, например, постоянно на 3-ю позицию сверху а предыдущие смещаются соответственно вниз.
>Записи добавляются, например, постоянно на 3-ю позицию сверху а предыдущие смещаются соответственно вниз.Значит так задумано при проектировании алгоритма работы с базой.
>>Записи добавляются, например, постоянно на 3-ю позицию сверху а предыдущие смещаются соответственно вниз.
>
>Значит так задумано при проектировании алгоритма работы с базой.
Да нет, я в скрипте совсем не трогаю указатель.см.выше.
Обычно это бывает после удаления нескольких последних записей%
может чего из-за этого
Я никогда не работал с MySql, но возможно смогу подсказать куда рыть, ибо в ораклятине приблизительно так:
если записи хранятся по ROWID, то при селекте без ордер бай, они выбираются отсортированными по ROWID. И uldus прав - когда идет голый delete, то перестроения ROWID не происходит и новые записи пишутся на место старых - это стандартный подход реляционных движков.
>Я никогда не работал с MySql, но возможно смогу подсказать куда рыть,
>ибо в ораклятине приблизительно так:
>если записи хранятся по ROWID, то при селекте без ордер бай, они
>выбираются отсортированными по ROWID. И uldus прав - когда идет голый
>delete, то перестроения ROWID не происходит и новые записи пишутся на
>место старых - это стандартный подход реляционных движков.
спасибо за внимание.
А как с этим боротся не подскажете?
>>Я никогда не работал с MySql, но возможно смогу подсказать куда рыть,
>>ибо в ораклятине приблизительно так:
>>если записи хранятся по ROWID, то при селекте без ордер бай, они
>>выбираются отсортированными по ROWID. И uldus прав - когда идет голый
>>delete, то перестроения ROWID не происходит и новые записи пишутся на
>>место старых - это стандартный подход реляционных движков.
>спасибо за внимание.
>А как с этим боротся не подскажете?Вводи в таблицы БД дополнительное поле (типа автоинкрементного - не знаю какими средствами это можно сделать в mysql - я с ним тоже не работал) и выбирай данные с сортировкой по этому полю.
>>>Я никогда не работал с MySql, но возможно смогу подсказать куда рыть,
>>>ибо в ораклятине приблизительно так:
>>>если записи хранятся по ROWID, то при селекте без ордер бай, они
>>>выбираются отсортированными по ROWID. И uldus прав - когда идет голый
>>>delete, то перестроения ROWID не происходит и новые записи пишутся на
>>>место старых - это стандартный подход реляционных движков.
>>спасибо за внимание.
>>А как с этим боротся не подскажете?
>
>Вводи в таблицы БД дополнительное поле (типа автоинкрементного - не знаю какими
>средствами это можно сделать в mysql - я с ним тоже
>не работал) и выбирай данные с сортировкой по этому полю.id unsigned int not null auto_increment
и в конце
primary key(id) - чтоб сортировалось быстрее
Надо не delete, а truncate делать - через временную таблицу. Но это ерунда всё. В принципе ROWID особого прикладного значения не имеет. Сортировку можно (и нужно, если необходимо) производить в зависимости от модели данных (по полям даты, порядкового номера и т.д.) по ИНДЕКСИРОВАННЫМ полям - для увеличения скорости. Но увеличение числа индексов прямо пропорционально затратам на их обслуживание (память, время на перестроение и т.п.).
Решай с заказчиком. Если ему нужна именно физическая последовательность, в ораклятине вешается триггер на индексное поле, который берет очередное значение sequence. Собственно и все - если ты добавил запись 10-й, то она будет иметь в поле индекса 10, независимо от физического размещения на диске.
Всем спасибо. Дело в том, что запись физически должна бы вставать на последнее место. Т.к скрипт upgat' -ит именно последнюю запись. Но наверное проблема решена: нужно перед этим делать select по id, которое есть в таблице ;)
>Всем спасибо. Дело в том, что запись физически должна бы вставать на
>последнее место. Т.к скрипт upgat' -ит именно последнюю запись. Но наверное
>проблема решена: нужно перед этим делать select по id, которое есть
>в таблице ;)Насколько я понял этот скрипт желает обновлять именно последнюю запись, а ты под него подстраиваешься. Тебе уже говорили, что привязываться к физическому расположению записи в таблице не есть хорошо. Лучше исправь скрипт чтобы он делал update table set ... where ID=:ID_VALUE.
>>Всем спасибо. Дело в том, что запись физически должна бы вставать на
>>последнее место. Т.к скрипт upgat' -ит именно последнюю запись. Но наверное
>>проблема решена: нужно перед этим делать select по id, которое есть
>>в таблице ;)
>
>Насколько я понял этот скрипт желает обновлять именно последнюю запись, а ты
>под него подстраиваешься. Тебе уже говорили, что привязываться к физическому расположению
>записи в таблице не есть хорошо. Лучше исправь скрипт чтобы он
>делал update table set ... where ID=:ID_VALUE.так я именно так и делал всегда, только перед этим был select * from ???;
и последняя запись была не последней добавленной и из нее брался id и делался update. Но проблема решилась добавлением в select :
select * from ??? order by id;
кстати подсказали. А за помошь всем спасибо.
все это конечно решает мои проблемы, но не решает проблем управления текущим указателем в таблице. Ведь на него управы так и не нашлось через dbd:dbi. Я нашел как им можно рулить через api для mysql, но как через dbd:dbi пока не известно...
Не знаю что это за ТвойSQL такой, если тебя волнует куда он засунул запись. Да какая нафиг разница, какое у него ROWID ! Есть сиквенс (объект БД - целочисленная последовательность, инкрементируемая при каждом селекте из нее, возможно циклическая, стартующая с указанного значения), который гарантирует послежовательность номеров в индексном поле. Все. Индексная колонка - такая же колонка, как и все остальные. Если ты сам будешь ковыряться в ROWID ты рискуешь как минимум затормозить движок базы, а как максимум грохнуть ее совсем. ROWID - системный ресурс, такой же как номер процесса в оси и нефиг его лапать.
Совсем же будет весело, если придется смигрировать твою базу в другой сервер. Мамой клянусь - там ВСЕ rowid'ы будут другие и отличаться будут может на порядки(!). А сиквенс тащится вместе с таблицей и триггером и запускается с нужного тебе значения.
Успехов.
>Не знаю что это за ТвойSQL такой, если тебя волнует куда он
>засунул запись. Да какая нафиг разница, какое у него ROWID !
>Есть сиквенс (объект БД - целочисленная последовательность, инкрементируемая при каждом селекте
>из нее, возможно циклическая, стартующая с указанного значения), который гарантирует послежовательность
>номеров в индексном поле. Все. Индексная колонка - такая же колонка,
>как и все остальные. Если ты сам будешь ковыряться в ROWID
>ты рискуешь как минимум затормозить движок базы, а как максимум грохнуть
>ее совсем. ROWID - системный ресурс, такой же как номер процесса
>в оси и нефиг его лапать.
>Совсем же будет весело, если придется смигрировать твою базу в другой сервер.
>Мамой клянусь - там ВСЕ rowid'ы будут другие и отличаться будут
>может на порядки(!). А сиквенс тащится вместе с таблицей и триггером
>и запускается с нужного тебе значения.
>Успехов.А MySQL вообщ мало подходит для обращения к ней из перловского DBI. Она настолько специфична, что никак не может быть описана через стандартные интерфейсы. Тут даже более подходит PHP, который представляет собой просто обертки к стандартный функциям mysql api.