И что будет, если в этот замечательный момент другой поток вставляет запись? =))))
seosniks: Первым запросом создаёте запись, получаете её ID, после выполнения запроса (INSERT). Вторым запросом вписываете в неё вычисленное на основе ID значение(UPDATE), или например удаляете запись, если она вдруг не нужна.
Те же яйца вид сбоку - что произойдет если другой поток вставит запись до "второго" запроса?
Решается такая задача либо транзакциями с локом на таблицу либо обеспечением уникальности id - напр использованием GUID
Еще один вариант - вставляете новую запись причем в ваше поле image записывайте GUID. После этого делайте апдейт:
Jaf4: А он жмот и извращенец (любитель поднимать сервера на винде) наверное неимоверный, т.к. стоимость канадского дедика у нас, в России, даже по нашим меркам невелика. 😂
Я ошибся, это сайт номер 1 в US, CAD, AU, NZ и UK
2 web servers, 3 DB servers, 30 млн хитов в день, это когда основатель один работал и занимало это у него пару часов в день
Доход 30 млн зеленых в год, 17 млн зарегестрированных пользователей
Кстати програмерам ставится 30'' эпловский монитор, всего работает 8 человек в конторе включая буха
Хороший пример что на самом деле можно выжать с MS продуктов. Но лично я не понимаю как ему это удалось
netwind: iopiop, просто покажи где в SQL92 прямо или косвенно написано, что ORDER BY указанный в подзапросе ДОЛЖЕН (а не может) привести к выдаче отсортированного результата во внешнем запросе. ну или любой другой доступный стандарт на SQL.
загадками говорите. при чем здесь SQL92, если я как раз и предлагаю подзапрос выбросить?
netwind:
А убрать SELECT - это уже нарушение стандарта. Тогда ТОЧНО не будет ничего выводить. Этот программист опирался на те вещи, которые явно зафиксированы, а не на экспериментальные данные о поведении mysql. И его код будет работать правильно во всех версиях mysql. А на что опирается твой вариант?
ну мне не сложно еще раз повторить
mysql_query("select*from textos where (user1 = '$user1' and user2 = '$user2') or (user1 = '$user2' and user2 = '$user1') order by datetime desc limit 10")
у какого вендора СКЛ этот запрос может работать не правильно (с поправкой на синтаксис ессно, limit -> top) ?
netwind: iopiop, разные варианты можно предположить. Я бы использовал здесь подзапрос для того чтобы отделить логику от представления. На php останется только приделать шаблонный цикл не загромождая его дополнительно логикой в виде еще одной сортировки.
не нужно еще одной сортировки, уже все отсортировано
netwind:
Ну и подзапросы не всегда плохие. Поэтому двойной order by никак не хуже. Так же, я обратил внимание на слова "записи-то уже отсортированы" - это неверно. Если убрать самый внешний order by, то порядок выдачи не гарантируется (в абстрактной реализации SQL). На php массив реально придется сортировать, не просто вывести в обратном порядке. Этот код был бы неемкий и только загромождает все.
ключевое слово "если". мы-то не рассматриваем коня в вакууме. "если" убрать селект, так вообще ничего выводиться не будет, не так ли? а "если" дроп поставить, так вообще таблица исчезнет ;-)
mysql_query("select*from (select*from textos where (user1 = '$user1' and user2 = '$user2') or (user1 = '$user2' and user2 = '$user1') order by datetime desc limit 10) t order by datetime asc"
я предлагаю его поменять на
mysql_query("select*from textos where (user1 = '$user1' and user2 = '$user2') or (user1 = '$user2' and user2 = '$user1') order by datetime desc limit 10")
и поменять порядок обхода массива в пхп на обратный.
так понятнее что я имел ввиду под "уже", "записи два раза сортируются" и "не нужно вложенного запроса" ?
Потому что в абстрактном SQL этот порядок не гарантируется, но в mysql можно не сортировать. Ну и некоторым удобнее вложить больше логики в SQL, чем вспоминать как там в php работать с массивами. Тем более это пара символов.
1. я не просто так выделил жирным "уже". посмотрите на запрос, записи два раза сортируются
2. да там вроде в любом случае с массивом работать, что так, что эдак. именно поэтому и не понятна двойная сортировка, зачем?
И что будет, если в этот замечательный момент другой поток вставляет запись? =))))
seosniks:
Первым запросом создаёте запись, получаете её ID, после выполнения запроса (INSERT). Вторым запросом вписываете в неё вычисленное на основе ID значение(UPDATE), или например удаляете запись, если она вдруг не нужна.
Те же яйца вид сбоку - что произойдет если другой поток вставит запись до "второго" запроса?
Решается такая задача либо транзакциями с локом на таблицу либо обеспечением уникальности id - напр использованием GUID
Еще один вариант - вставляете новую запись причем в ваше поле image записывайте GUID. После этого делайте апдейт:
UPDATE table SET image = id WHERE image=$GUID
А можно урл сего чудо сайтика увидеть :?
Ибо топ 1 по US, CAD, AU, NZ и UK и всего 17кк анкет как-то не сходится.
Вы случаем сию инфу не у отдела маркетинга Майкрософта почепнули ?
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
ето потому что тут задача изначально нестандартная - самые свежие записи должны снизу :-)
так что тут наоборот разрыв шаблона случится, как так, выводить надо наоборот, а шаблон стандратный :-)
iopiop, просто покажи где в SQL92 прямо или косвенно написано, что ORDER BY указанный в подзапросе ДОЛЖЕН (а не может) привести к выдаче отсортированного результата во внешнем запросе. ну или любой другой доступный стандарт на SQL.
загадками говорите. при чем здесь SQL92, если я как раз и предлагаю подзапрос выбросить?
А убрать SELECT - это уже нарушение стандарта. Тогда ТОЧНО не будет ничего выводить.
Этот программист опирался на те вещи, которые явно зафиксированы, а не на экспериментальные данные о поведении mysql. И его код будет работать правильно во всех версиях mysql. А на что опирается твой вариант?
ну мне не сложно еще раз повторить
у какого вендора СКЛ этот запрос может работать не правильно (с поправкой на синтаксис ессно, limit -> top) ?
iopiop, разные варианты можно предположить.
Я бы использовал здесь подзапрос для того чтобы отделить логику от представления. На php останется только приделать шаблонный цикл не загромождая его дополнительно логикой в виде еще одной сортировки.
не нужно еще одной сортировки, уже все отсортировано
Ну и подзапросы не всегда плохие. Поэтому двойной order by никак не хуже.
Так же, я обратил внимание на слова "записи-то уже отсортированы" - это неверно. Если убрать самый внешний order by, то порядок выдачи не гарантируется (в абстрактной реализации SQL). На php массив реально придется сортировать, не просто вывести в обратном порядке. Этот код был бы неемкий и только загромождает все.
ключевое слово "если". мы-то не рассматриваем коня в вакууме. "если" убрать селект, так вообще ничего выводиться не будет, не так ли? а "если" дроп поставить, так вообще таблица исчезнет ;-)
iopiop, спрашивали ЧТО ЭТО, а не как пишут люди, которым неудобно писать SQL.
ну а я спросил ЗАЧЕМ.
а вы зачем-то стали рассказывать про негарантированность порядка выдачи, хотя в данном случае она гарантирована
netwind, есть запрос
я предлагаю его поменять на
и поменять порядок обхода массива в пхп на обратный.
так понятнее что я имел ввиду под "уже", "записи два раза сортируются" и "не нужно вложенного запроса" ?
Потому что в абстрактном SQL этот порядок не гарантируется, но в mysql можно не сортировать.
Ну и некоторым удобнее вложить больше логики в SQL, чем вспоминать как там в php работать с массивами. Тем более это пара символов.
1. я не просто так выделил жирным "уже". посмотрите на запрос, записи два раза сортируются
2. да там вроде в любом случае с массивом работать, что так, что эдак. именно поэтому и не понятна двойная сортировка, зачем?
Зато без вложенного запроса обойтись можно