d_v_c

Общие советы:

Во первых, почитайте как работает DISTINCT - он тут совершенно не при чем.

Во вторых, категорически не рекомендую использовать запрос GROUP BY с указанием в select полей которые не участвуют в группировке / не обработаны агрегирующими функциями. Строго говоря содержимое таких полей может быть достаточно произвольным + на правильно сконфигурированном sql будет ошибка синтаксиса.

Конкретные советы:
Либо получать вложенным запросом типа

select tmp.*, Aincrad\Models\Messages.message
FROM (
  select author, recipient, max(id) as maxid
  from Aincrad\Models\Messages msg
) tmp
join Aincrad\Models\Messages on Aincrad\Models\Messages.id = tmp.maxid

что будет весьма медленно, либо создать еще одну таблицу в которой явно хранить именно последнее сообщение диалога.

Начнем с того, что бесплатной она не является https://firebase.google.com/pricing/
Большие объемы Вы там хранить разоритесь.

В официальной документации есть вполне понятный REST API и даже библиотека для php на гитхабе
https://firebase.google.com/docs/database/rest/start
https://github.com/ktamas77/firebase-php

Ну и в целом - сам не щупал, но судя по гайдам и ценам - основное применение это убрать необходимость разработки бекенда к мобильным приложениям, путем прямых запросов в БД.

SELECT
   FROM_UNIXTIME(time) AS formatted_date, 
   user1.username AS user1_username, 
   user2.username AS user2_username
FROM table1
LEFT JOIN table2 as user1 on user1.ID = table1.userID1
LEFT JOIN table2 as user2 on user2.UD = table1.userID2

В Вашем конкретном случае - ответ нет.
Начинать нужно всегда с 3НФ, т.е с

User:
id
username
password_hash
full_name
и т.д

Уже потом по мере роста проекта будете заниматься денормализацией

Занимался системой коллективной лояльности полтора года.

Тут много неясного не с точки зрения программирования, а в первую очередь с юридической.

Во первых Вам нужно определиться с правовым статусом этих бонусов - это деньги или не деньги.
Если деньги - нужно реально открывать счет на клиента в банке или НКО, платить за клиента 13% ндфл, ну и все прелести 161-ФЗ.
Если не деньги - возникает вопрос обоснования финансовых переводов между юрлицами ну и накрывается идея выплат на карту.
Решения однозначного нет, каждая система лояльности идет по своему пути но в целом разработка схемы и юридического обоснования это месяцы.

С технической стороны - могу навскидку озвучить множество вариантов реализации, но отталкиваться нужно от потребностей партнеров:
Можно опубликовать свой шлюз наружу и надеяться что с ним будут интегрироваться.
Можно интегрироваться на уровне учетного ПО / сайта / crm партнеров подготовив модули под основные системы.
Можно делать пост-аналитику банковской выписки партнера.
Можно запустить отдельные интерфейсы на своей стороне с минимальной интеграцией.
В одних сферах бизнеса партнеров лучше работает одно, в других - другое.

PS
Судя по вопросу Вы только в начале этого пути.
Крайне советую до начала проекта:
а) Проработать юридическую часть.
b) Найти первых якорных партнеров. Заодно поймете как им удобней с Вами интегрироваться.
В целом советую по крайней мере на старте идти по пути максимально простой для партнера интеграции.
Простой с точки зрения бизнеса (!), а не разработчика.

Как осуществляется написание платежной системы касательно visa и mastercard или для конкретного банка? что делается в данном случае? (Допустим требуется работа со сбербанком и альфабанком).

Из личного опыта:
a. Приезжаете в офис банка у которого есть услуга "интернет эквайринг", показываете своё юрлицо, уставные документы, бенефициаров, обороты от 50 млн в месяц.
* некоторые работают и с меньшими оборотами, но % будет крайне не выгодным.
** без запущенного и работающего проекта идти в банк бессмысленно.
b. Ждете 2-6 недель пока СБ банка проверит все.
c. Ждете 2-4 недели пока банк подпишет договор
d. Получаете реквизиты и документацию API конкретного банка.
e. Реализуете
f. Ждете 1-2 недели пока банк проверит что у Вас все согласно их протоколу.
g. Получаете боевые реквизиты.

Учтите что:
1. Если Ваши объемы меньше чем 50млн+ в месяц - с вероятностью 99% Вам будет СИЛЬНО выгоднее работать через посредника. Посмотрите на uniteller.ru , payture.com/ru , payler.com - если Вы будете достаточно убедительны на переговорах, вполне реально сторговать их до 2-2.5% даже на маленьких оборотах (1млн-5млн)

2. Прямые API банков мягко говоря не современны. Как правило там не будет ни удобного личного кабинета, ни вменяемой службы поддержки - ничего. Зато будут проверки, требования бумажной отчетности и прочие милые сердцу советского бюрократа вещи.

3. Риски при работе через посредника - по факту минимальны. Все приведенные выше делают выплаты ежесуточно, т.е даже если посредник накроется - Вы максимум рискуете дневным оборотом.

С учетом данных пунктов, по моему мнению прямой договор с банком имеет смысл если у Вас настолько большие обороты - что разница в десятые доли процента окупает весь этот геморрой.
По факту есть море проектов с большими оборотами (mamba, badoo, etc) кто продолжает работать через агрегатор, минимизируя расходы на юристов, бухгалтеров, техническую поддержку работы шлюза итд итп.

1. Задача не трудоемкая. Постоянно обрывать подключение и делать заново - не лучшая идея, если есть возможность сделать через постоянное подключение - это даст выигрыш в скорости. Тип таблицы однозначно innodb

2. Весьма вероятно что задачу можно отлично решить без sql вообще, через какой нибудь redis - будет быстрее на порядки.

Если прям очень хочется, то как правильно написал Greg Popov запрашиваем у пользователя права на просмотр его записей (user_posts permission ), смотрим, сверяем.

На практике можно поймать негативный фидбек от людей, т.к лишние права никому не нравятся
+ сильно усложняется обработка (не забываем что пользователь может выборочно отключать права приложения)

PS С учетом того что ничего не запрещает пользователю удалить пост в любой момент после публикации - как то технически контролировать это все смысла ровно 0. Придумывайте маркетинговые стимулы реально делать share.

Режим телепата:
1) у Вас просто нет индекса в таблице cities по полю country_id.
Покажите результат выполнения show create table cities;
2) если mysql запущен с дефолтными конфигами - ему тупо не хватает памяти.