Те же яйца вид сбоку - что произойдет если другой поток вставит запись до "второго" запроса?
Решается такая задача либо транзакциями с локом на таблицу либо обеспечением уникальности id - напр использованием GUID
Еще один вариант - вставляете новую запись причем в ваше поле image записывайте GUID. После этого делайте апдейт:
UPDATE table SET image = id WHERE image=$GUID
http://highscalability.com/plentyoffish-architecture
Достаточно интересна монетаризация -дается реклама конкурентов, но конкуренты платные, а plentyoffish бесплатные
Я ошибся, это сайт номер 1 в US, CAD, AU, NZ и UK
2 web servers, 3 DB servers, 30 млн хитов в день, это когда основатель один работал и занимало это у него пару часов в день
Доход 30 млн зеленых в год, 17 млн зарегестрированных пользователей
Кстати програмерам ставится 30'' эпловский монитор, всего работает 8 человек в конторе включая буха
Хороший пример что на самом деле можно выжать с MS продуктов. Но лично я не понимаю как ему это удалось
самый популярный канадский сайт знакомств живет у владельца в подвале.
2 компа, полностью на продуктах от MS - винда, IIS, ASP, MS SQL
ето потому что тут задача изначально нестандартная - самые свежие записи должны снизу :-)
так что тут наоборот разрыв шаблона случится, как так, выводить надо наоборот, а шаблон стандратный :-)
загадками говорите. при чем здесь SQL92, если я как раз и предлагаю подзапрос выбросить?
ну мне не сложно еще раз повторить
у какого вендора СКЛ этот запрос может работать не правильно (с поправкой на синтаксис ессно, limit -> top) ?
не нужно еще одной сортировки, уже все отсортировано
ключевое слово "если". мы-то не рассматриваем коня в вакууме. "если" убрать селект, так вообще ничего выводиться не будет, не так ли? а "если" дроп поставить, так вообще таблица исчезнет ;-)
ну а я спросил ЗАЧЕМ.
а вы зачем-то стали рассказывать про негарантированность порядка выдачи, хотя в данном случае она гарантирована
netwind, есть запрос
я предлагаю его поменять на
и поменять порядок обхода массива в пхп на обратный.
так понятнее что я имел ввиду под "уже", "записи два раза сортируются" и "не нужно вложенного запроса" ?
1. я не просто так выделил жирным "уже". посмотрите на запрос, записи два раза сортируются
2. да там вроде в любом случае с массивом работать, что так, что эдак. именно поэтому и не понятна двойная сортировка, зачем?
Зато без вложенного запроса обойтись можно