ThunderCat

Табличка из локальной базы, попадаются адреса в разных форматах.

Форма заполнения этой таблички не должна позволять отклоняться от существующих адресов(более-менее), как минимум населенный пункт/район/улица должны выбираться из готовых списков, а не вводиться в ручную.

А дальше при обновлении данных в базе и если адрес пользователя попал в список отключенных - шлём ему оповещение.

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

подводные камни - данные могут в течение дня несколько раз поменяться,

ничегоне мешает при исключении адреса из бд высылать ему "ой, ошибочка вышла"

а второе - поиск по адресной базе сомневаюсь что выйдет быстрым.

В итоговой базе у вас будет 3-4 числовых значения - код города, код района, код улицы. Номер дома и квартиры может быть в текстовом формате, но это короткое хорошо индексируемое поле. Все должно работать достаточно быстро, тем более что оповещений будет сильно меньше реальных пользователей.

установить кодировку соответствующей таблицы в utf8mb4.
После инициализации подключения должны быть запросы

SET character_set_connection = utf8mb4
SET character_set_client = utf8mb4
SET character_set_results = utf8mb4

ALTER TABLE `sometable` 
ADD COLUMN `id` INT AUTO_INCREMENT PRIMARY KEY,
AUTO_INCREMENT=100;

или создать по умолчанию, затем апдейтнуть ид на ид + 99

Кошмарус максимус...
ладно все в лапше функциями, так еще и
1) в одной функции все в кучу - запросы, обработка, вывод...
2) это вы в каждой функции будете создавать / закрывать соединение где надо из базы 1 запись вытащить?
3) строка С ЗАПРОСОМ передается ПО ССЫЛКЕ, Карл!(экономим память епта!). Запрос как аргумент функции - вообще новое веяние...
4) при этом делаем: $query = $string; ... Не, ну а чо...

$GLOBALS это ваще жесть конечно... как и вставка гданных из гет в запрос(даже с какой-то обработкой), у вас же препэйреды по идее должны работать!

$STH = $GLOBALS["mysqlcon"]->prepare("
SELECT count(id) as count
FROM `post` 
WHERE MATCH (tags) 
AGAINST ('".clearStr($_GET['search'])."' 
IN BOOLEAN MODE)");

UPD: вам в любом случае придется делать 2 запроса, так как количество результирующих строк разное, кроме того каунт по первичному ключу будет быстрым, а выборка скорее всего сразу закешируется после первого запроса.

После подключения должны быть запросы

SET character_set_connection = utf8mb4
SET character_set_client = utf8mb4
SET character_set_results = utf8mb4

иначе клиент не знает в какой кодировке принимаются данные со стороны бд.

В принципе есть всего 2 варианта, оба варианта выше написали.
1) уникальный ключ по 2 полям
2) Селект по этим же полям и проверка на стороне ЯП на наличие записи

Оба варианта работать будут, однако я бы все же советовал бы использовать 2 вариант. Не смотря на то что вариант 2 имеет некоторую возможность коллизий(как верно заметил Rsa97), он не вызывает неоднозначности в выполнении, то есть он явно проверяет наличие строки, в то время как первый метод вызывает ошибку вставки по уникальному ключу на стороне БД, что гораздо сложнее обрабатывать. В целом ничего не мешает скомбинировать оба метода, тогда коллизий можно избежать, максимально ограничив количиство возможных ошибок предварительной проверкой.

похоже проблема в том что предыдущий запрос не отработал до конца в части отдачи результата из запроса в пхп. Попробуйте это почитать, может вы решите свою проблему, там в неосновном ответе есть настройки дополнительные.

хак

По уму - форматирование даты/времени отдается в яп, задача бд - хранить данные в определенном формате. Если критично сделать это именно средствами бд - используйте DATE_FORMAT, как выше отписал вам Андрей.

Я бы выбирал SELECT `DateTimeOp` As Dateи в яп уже парсил дату в нужный формат.

по уму что-то такое должно быть:

class Category extends Model{
    public $table = 'category';
    public $db = false;
// вариант DI - передаем $db в конструктор
   public function __construct($db){
      $this->db = $db;
   }

//или вариант инициализации по id
   public function __construct($id=false){
      parent::__construct($id); 
// в базовом классе модели берем $db из регистра и присваиваем $this->db
   }
}

$categories = new Collection(new Category());
$categories = $categories->getArrayOfObjects();

Сразу скажу что не очень жалую вариант с DI, так как либо приходится делать синглтон, либо в каждом контроллере делать новый $db(что имхо бред), либо так же совать дб в регистри и тащить его при инициализации каждого объекта. Минус второго способа - IDE "не видит" как подключен дб и интелисенс и прочие плюшки не работают.

Если вы о том что бы в результатах запроса данные были многоуровневым массивом, то так не будет работать, результат выборки - всегда набор строк, можно только объеденить все данные в 1 строку, как выше предложил idShura.

у вас сравнивается "... время сейчас больше чем время сейчас минус 10 минут", что всегда будет true. вы там даже не упоминаете поле даты...

А может сначала по-православному? Индексы, слоулог, експлэйн...?

как уже заметил eRKa это логика уровня приложения, и к бд прямого отношения не имеет. Проверка должна выполняться в серверном приложении, и как верно предложил dollar - сначала селект - по результату инсерт.

Вариант делать перед insert-ом select (в котором проверять это условие) не подходит. Так как серия select-ов выполняется моментально, условие выполняется и затем все равно идет серия insert-ов.

Ошибка на фразе "срия select-ов выполняется моментально". Каждый селект будет выполняться ПОСЛЕДОВАТЕЛЬНО, при условии лока таблиц на чтение для инсерта. И ничего не выполнится моментально, все будет по порядку.

SET character_set_connection = utf8mb4;
SET character_set_client = utf8mb4;
SET character_set_results =  utf8mb4;

Вроде это при установке соединения указать надо, не уверен что они не сбиваются при клиентском подключении.
PS: не уверен, но вроде же COLLATE utf8mb4_general_ci;
тут еще посмотрите