|
Задавайте вопросы, мы ответим
Вы не зашли.
При добавлении данных, строки в таблицу добавляются так, что сортируются задом наперед.
хм, даже и не знаю как описать то верно..
поле ID добавляется автоматически, с этом все ок.
Но при запросе потом в таблицу, данные выдает так, если бы стояла сортировка order by id desc
И если смотреть таблицу в phpMyAdmin, то же самое, строки в обратном порядке.
Притом добавленные ранее строки расположено как и нужно по id
смотрится странно...
к примеру:
эти строки добавлены ранее
ID | Name
1 name1
2 name2
3 name3
а тут строки добавленные позже
7 name7
6 name6
5 name5
4 name4
Выстраивается все как положено только если сортировку указать принудительно.
Но так как, в таблице более миллиона строк, указывать при выборке сортировку не хотелось бы, так как сразу возрастает время запроса.
Где я прогулял уроки, когда это рассказывали? :)
PS:
Данные для добавления в базу берутся из текстовых файлов.
Функция читает построчно файл, и каждую строку, после перекодирование её в UTF8, добавляет соответственно в новую строку таблицы.
Причем в основном все работает отлично, однако иногда случается то что я описал выше.
Сначала я думал, что что то в файлах, однако одни и те же файлы, одни раз парсятся и добавляются в базу "шиворот-навыворот", а иной раз правильно
Неактивен
Причем в основном все работает отлично, однако иногда случается то что я описал выше.
Сначала я думал, что что то в файлах, однако одни и те же файлы, одни раз парсятся и добавляются в базу "шиворот-навыворот", а иной раз правильно
Следовательно, смотрите функцию, которая их разбирает. И далее...
Притом добавленные ранее строки расположено как и нужно по id
смотрится странно...
Насколько я знаю, порядок добавления в БД никто не гарантирует. И порядок выборки, также.
Поэтому, надо указывать сортировку.
Но так как, в таблице более миллиона строк, указывать при выборке сортировку не хотелось бы, так как сразу возрастает время запроса.
Другого варианта, без извращений, - нет.
Зачем вам выбирать миллион строк каждый раз?
Вы думаете, что пользователь их все охватит одним взглядом?
Или вы делаете с ними что-то такое, что не может сделать сервер?
Как вариант, есть LIMIT.
Неактивен
Для MyISAM есть специальная операция:
Неактивен
Артём Н. написал:
Причем в основном все работает отлично, однако иногда случается то что я описал выше.
Сначала я думал, что что то в файлах, однако одни и те же файлы, одни раз парсятся и добавляются в базу "шиворот-навыворот", а иной раз правильноСледовательно, смотрите функцию, которая их разбирает. И далее...
Притом добавленные ранее строки расположено как и нужно по id
смотрится странно...Насколько я знаю, порядок добавления в БД никто не гарантирует. И порядок выборки, также.
Поэтому, надо указывать сортировку.Но так как, в таблице более миллиона строк, указывать при выборке сортировку не хотелось бы, так как сразу возрастает время запроса.
Другого варианта, без извращений, - нет.
Зачем вам выбирать миллион строк каждый раз?
Вы думаете, что пользователь их все охватит одним взглядом?
Или вы делаете с ними что-то такое, что не может сделать сервер?
Как вариант, есть LIMIT.
Я же указал, что функция работает нормально, и только в некоторых случаях, причем с одной и то же книгой может один раз добавить правильно а другой нет...
Конечно, вопрос к функции возникает сам собой, однако не думаю.
что вы имеете ввиду "порядок добавления в БД никто не гарантирует"
порядок добавления гарантирует auto_increment.
А вот о выборке таки да, в доку стоит что может не соответствовать, однако на практике почти всегда все ок.
Так что я не против сортировке, но интересен сам факт такого "изнаночного" добавления строк.
да...
нет конечно, и в страшном сне мне не привидится пытаться загрузить в скрипт миллион строк...
Но вообще то, если вы указали order by то от общего количества строк, независимо от LIMIT, напрямую зависит время запроса.
Неактивен
rgbeast написал:
Для MyISAM есть специальная операция:
ALTER TABLE mytable ORDER BY id;
Но порядок может сбиваться при каждой вставке.
О! Спасибо. Выход есть
Хотя я уже во все запросы, где было необходимо добавил order by.
Но это выход. Так как можно просто в скрипт прописать запрос типа
rgbeast написал:
Но порядок может сбиваться при каждой вставке.
И о теории, есть где почитать об этом?
Неактивен
Теория очень простая — MyISAM вставляет строки в освободившиеся после DELETE
место, если оно есть, и в конец, если его нет
А ORDER BY — это правильно, т.к. без него никто, разумеется, не гарантирует пра-
вильный порядок строк.
Неактивен
Я же указал, что функция работает нормально, и только в некоторых случаях,
причем с одной и то же книгой может один раз добавить правильно а другой нет...
Вы не говорили про функцию. Вы говорили про файлы:
Atapin написал:
Сначала я думал, что что то в файлах, однако одни и те же файлы,
одни раз парсятся и добавляются в базу "шиворот-навыворот", а иной раз
правильно
Конечно, вопрос к функции возникает сам собой, однако не думаю.
Функция, прежде всего.
что вы имеете ввиду "порядок добавления в БД никто не гарантирует"
порядок добавления гарантирует auto_increment.
ID автоинкрементный?
В любом случае, как я понимаю, порядок вставки не гарантируется.
Автоинкремент значит примерно следующее:
"Запись, которая будет вставлена, получит текущее значение счётчика.
Затем, счётчик будет увеличен."
И всё. Никто не говорит где будет вставлена запись.
И после какой записи она последует.
Если, я не ошибаюсь, конечно.
однако на практике почти всегда все ок.
Ну да, видимо, сейчас как раз тот случай, когда это не так.
Но вообще то, если вы указали order by то от общего количества строк,
независимо от LIMIT, напрямую зависит время запроса.
Ну да. Только вряд ли очень сильно. Хотя, я не знаю.
ALTER TABLE mytable ORDER BY id;
Но это выход. Так как можно просто в скрипт прописать запрос типа
ALTER TABLE mytable ORDER BY id;
после добавления данных.
Сомневаюсь, что это выход.
Во-первых, не факт, что это будет быстрее, чем ORDER BY.
Во-вторых, ALTER TABLE - не очень хорошая идея.
Отредактированно Артём Н. (24.05.2010 21:34:48)
Неактивен
