Для начала: получаете не первую запись, а случайную. Случайная, как правило, оказывается первой попавшейся, т.е. первой. Если сделать (допустим) alter table order by id desc то случайная, как правило, начнет оказываться последней при группировке. Это кстати можно назвать 0 вариантом, но он ненадежный, ибо "как правило" может и не сработать.
1 тяжелый в среднем по палате и при прочих равных хуже, т.к. хуже масштабируется и легче застревает, плюс может не попадать в кэш и легко жрет память.
Тогда все же немного абстрактно (таблиц Ваших у нас нет для теста, ну и нужные данные приджоинить уже сможете сами).
1 вариант.
select a.* from pm as a left join pm as b on (a.user1_id=b.user_1_id && a.user2_id=b.user2_id) and a.pm_id<b.pm_id where b.pm_id is null group by a.pm_id
В чем смысл - джоинится таблица сама на себя, так что бы "слева" были более ранние сообщения чем "справа". После чего с помощью b.pm_id is null отсекаются все строки для которых в правой таблице хоть что-то есть (т.е. есть более поздние записи). Естественно к этому можно доджоинить любые нужные данные или добавить where в этот запрос что бы выбрать "неудаленные и непрочтенные".
2 вариант
select * from messages where pm_id in ( select max(pm_id) from pm group by user1_id, user2_id )
В чем смысл - во вложенном запросе Вы выбираете наиболее ИД наиболее поздних сообщений для всех пар юзеров, после чего уже делаете выборку из таблицы сообщений конкретно по этим ИД (внешний запрос естественно можно расширить джоинами для того что бы выцепить данные из таблицы юзеров и т.д. или добавить where по удаленным и непрочтенным).
3 вариант
Он не вполне решение Вашей постановки задачи, но как ни странно, он наиболее умное решение вопроса с точки зрения нагрузки. Добавьте еще одно поле - последнее непрочтенное сообщение. Выставляйте его при прочтении сообщений юзером, это будет один маленький редкий запрос, который сэкономит Вам в будущем кучу нервов и времени.
Решение есть, при чем достаточно шустрое, общая мысль тут в первом абзаце
/ru/forum/comment/5029477 .
Смысл тут в том, что бы выбрать только те значения, для которых значения с бОльшей датой не существует (джоиним таблицу с постами саму на себя соединяя по дате и оставляем только те строки, в которые приджоинить ничего не удалось).
Другое решение - вложенный мускул запрос, т.е. используете select max(postid) по нужным фильтрам и потом уже делаете выбор полных данных по типу select (полные данные) from ( select max(postid) по нужным фильтрам ). Но все это в одном sql запросе, просто используя вложенные.
Более традиционен и понятен второй вариант.
Более быстр первый.
На пхп такую задачу решать это маразм конечно.
p.s.: думается сейчас плохо, если нужно точный запрос - вечером накидаем.
Рыба не бывает второй свежести. Вы заявили что ограничения нет вообще.
На сайте ВМ и на эксченджере вся информация есть.
Оба мнения неправильные.
Налог надо платить с тех ВМ от которых избавляешься.
Не важно что ты за них получаешь - реальные деньги, услуги, пополнение счета у мтс, ценные бумаги другого вида или еще что-то.
Момент налогообложения возникает в момент избавления от ценных бумаг, размер определяется как полученная выгода при этом.
В принципе это ближе ко второму мнению, но! если программер у Вас попросил 100р или 100вмр, то расплатившись 100вмр-ками - Вы тут же должны забежать в налоговую и отдать им 13 рублей вместе с 3-ндфл (тут же - условно - до 1 апреля следующего года).
Глубоко, сильно.
Достаточно 240 тысяч и одной копейки, что бы уже начать экономить. А еще есть пеймер чеки, которые вообще условно-бесплатны.
HeroFold, Вы контекст топика не забывайте. Какая-бы хитровыебвыдуманная схема не была внутри ВМ - в контексте вывода через АГ все достаточно понятно, договор о покупке ценных бумаг у Вас и приход денег на счет.
Хотите детальнее понять "для себя", нате ссылку http://www.guarantee.ru/information , курите на здоровье, особенно предпоследнюю ссылку, все разжевано не то что для бухгалтеров, даже для программистов и всего 72 страницы 😂
До вот этого опуса нам казалось что Вы искренне заблуждаетесь, но теперь это больше похоже на какой-то унылый копирайтинг по чьему-то заказу.
Если теслы выйдут из статуса игрушек, то электричество для них перейдет в статус топлива. В бензине доля налогов, акцизов и прочего - до 70% доходит, в электричестве ноль. Даже если не смогут эти 70% засунуть в цену электричества - перенесут их в транспортный налог или еще какие-нибудь сборы. То на то и выйдет.
Верно. Незнакомого с математикой человека это может смущать и ему действительно может казаться что он платит проценты вперед.
Этим в частности пользуются всякие а) копирайтеры которым надо на сайт свой затащить людей под девизом "банки вас обманывают, требуют проценты вперед" б) юристы, которым надо оказать консультацию или даже взять дело под девизом "вы мне сейчас заплатите, а я вам столько денег может быть отсужу" в) кредитные брокеры заявляющие - ну на самом деле не так много вы переплачиваете по ипотеке, выплатите досрочно - проценты можно будет вернуть - в общем полный набор стервятников который наживается на этом... а так же те кто на это купился.
Эту "разницу" отсудить невозможно. Потому что проценты вперед не платятся. То что вначале они больше, чем в конце, так это объясняется тем простым фактом, что в начале сумма долга больше чем в конце, а проценты начисляются на сумму долга.
Подавайте заявку в вебмани, обосновывайте и включат http://www.webmoney.ru/rus/cooperation/guarantors.shtml
Нет никаких "уплаченных вперед" процентов при аннуитете (так же как и по дифференциалу). Возмещать при досрочном погашении, как следствие, нечего.
