Станислав Б

А просто со временем, до всех доходит, что программирование это не интересные исследования, познания неведомого как в фантастике, прикручивание двумя кликами новых движков.
А на деле - это еще и множество рутинной и кропотливой работы, которая по сути - скучная, однообразная, И ее процентов 80.

Вы это наконец поняли. Какую мотивацию вы хотите от нудной и кропотливой работы - неясно. Мотивация может быть в зарплате, в создании своего продукта, если он есть. А так - человек должен уметь мотивировать себя сам, а не ждать пока его рассмешат клоуны.

Лезу в класс Main и вижу что метода sayHelloWorld в нём нет. Логически понятно что он не в родителе т.к. было бы другое обращение (через parent::) но это всё равно несколько сбивает с толку, особенно если слово use не сразу заметишь

Установите нормальное IDE и не будет никаких проблем, например в том же PHPStorm кликнув на методе Вы сразу можете перейти к его реализации без лишних поисков и телодвижений

Есть ли какие-то best practice и негласные соглашения по их использованию, например писать метод $o->sayHelloWorldTrait(); тогда уже по названию метода понятно и что он делает и откуда берётся.

Ой сомневаюсь, ибо смысла в них нет. Название метода эта часть интерфейса класса, а трейт он как бы не относиться к описанию интерфейса. Трейт это инструмент позволяющий избавиться от дублирования функционала и не более того.

В какой папке хранить трейты если папки проекта разделены на model, view, controller?

А трейты у Вас к чему относятся? к бизнес-логике, логике обработки запросов или представлению? К какому слою относиться трейт в том и размещайте

Вопрос по статическим членам трейта

Зачем мешать молоко с мухами? Конфиги это - не функционал программы, соответственно смысла размещать их в трейтах вообще нет

Открываем документацию php.net/manual/ru/function.ksort.php

Возвращаемые значения

Возвращает TRUE в случае успешного завершения или FALSE в случае возникновения ошибки.

C++ не может повредить. Если вы используете virtual, RTTI, exceptions, iostreams, то вы платите за них, но если эта цена неприемлема - просто не используете их.

Однако C++, особенно C++11 и C++14, часто не поддерживаются компилятором, когда приходится собираться не под уютные gcc/clang x86, а что-нибудь специфическое, вроде Arduino или CUDA. Ещё в ядре Linux C++ традиционно под запретом.

Так что посмотрите, можете ли вы использовать C++ в вашем конкретном случае. Если нет, то выбирать не из чего.

Здесь плохо всё, к сожалению.

Начнем с того, что вы неверно наследуете классы. Почему у вас класс, отвечающий за подключение к базе данных является родителем класса, работающим с заказами? Наследование применяется, если можно сказать, что что-то является чем-то. Например, разработчик является работником; компьютер является устройством и тд. Здесь же у вас вообще близко такой логике не получится следовать. Вы должны передавать хотя бы объект для работы с бд через инъекцию, например, в конструктор. В идеале, нужно использовать паттерн репозиторий для работы с базой данных.

Класс SearchOrder у вас не только выполняет запросы, но еще и работает с данными, хранит состояние этих самых данных, фильтрует данные (strip_tags()). Непорядок. Это все нужно разделять. У вас вообще получаются какие-то богообъекты, которые умеют во все.

Вы каждый раз повторяете строки с подготовкой запроса, биндингом параметров, отправкой запроса и тд. Не думали, что неплохо бы было написать какую-нибудь обертку и выполнять запросы как-нибудь так:

$result = $wrapper->select("SELECT * FROM `tablename` WHERE `id` = :id", ['id' => 5]);

?

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

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

$this->orderID = (int) strip_tags($orderID);
$this->column = (string) strip_tags($column);
$this->value = (string) strip_tags($value);

?

Почему вы стриппите тэги у идентификатора? вы настолько не уверены в том, что влетает в функцию:
strip_tags($orderID);
?

Если вы не используете php 7 и, как следствие, скалярный тайпхинтинг, то должны делать проверки на тип входящего аргумента. Если что-то не так с типом, бросаем исключение (А не приводим его к нужному)! Например:

if (!is_string($arg)) {
    throw new InvalidArgumentTypeException('string', $arg);
}

Это в идеале. Вы не обязаны это делать, конечно же. Но вот такие проверки делают приложение безопаснее. Хотя, опять же, повторюсь, в 2017 нужно начинать новые проекты на php 7.1+.

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

Кроме всего прочего, почитайте про стандарты оформления кода. Вы им не следуете.

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

Желаю успехов!

Если invoke() обязан быть интерфейсным методом, то видится такое решение:
1) Интерфейс Invokable должен лежать в том же пакете, откуда он будет вызываться
2) В этом же пакете нужно создать некий package-private класс (проще всего - enum) с одним-единственным инстансом:

enum Lock { 
    LOCK;
 }

3) в метод invoke передавать Lock:

public static interface Invokable {
  public void invoke(@NonNull Lock lock);
};

4) В реализации дополнительно проверять переданный Lock на null
5) В месте "правильного" вызова передавать: model.invoke(Lock.LOCK);

Если метод invoke не обязан быть интерфейсным, то просто сделать его package-private и держать реализацию в том же пакете.

Но мне кажется, что где-то ошибка проектирования. Если изложишь задачу более подробно, можно найти более нормальное решение.

Безопасный подход для больших таблиц:

create unlogged table list_for_delete (id int);
insert into list_for_delete values ....

with to_rm as (
    select id from list_for_delete limit 10000
), rm as (
    delete from list_for_delete where id in (select id from to_rm)
)
delete from tablename  where id in (select id from to_rm);

vacuum analyze tablename;
drop table list_for_delete ;

cte с delete повторять пока не будет affeted rows = 0. Смотреть на лаг репликации, добавлять задержки между запросами и увеличивать/уменьшать размер пачки в зависимости от влияния на прод.
vacuum в конце, можно после половины пройтись дополнительно. С таким-то объёмом можно руками вакуум вообще не делать и оставить автовакууму. А для таблиц побольше при массовом изменении имеет смысл.