Max Ba

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

Если у вас всегда экземпляр класса User имеет одинаковые методы и поля, то и классов отдельных не нужно делать. Тем более что конкретно в вашем примере функционал юзера, можно отделить ролями/правами, которые могут быть реализованы позднее отдельно.

А почему бы не подсмотреть у популярных решений?
https://www.yiiframework.com/doc/guide/2.0/ru/db-q...

Я так понимаю Ваш ->filter('email', 'test@test.ru'); может строить только 1 тип запроса. А если надо like, <> и т.д.? Будете другой метод создавать?

И согласен с Александр Аксентьев, new Invoice(DB::init()) это очень странно, согласитесь более красиво выглядит Invoice::find()

Нет в коде понятия правильно или неправильно самописном, если это не совсем трешак или лапша.
Работает или нет - главный критерий.
Нравится или не нравится(самому) - второй по важности критерий.

PDO не пишет за тебя SQL. Он может выполнить только тот запрос, который ты сам смог написать. Поэтому фраза "PDO умеет как-то работать без LIMITа" не имеет смысла.

Так что сами запросы оставляй как есть.
Переделывать под ПДО имеет смысл всегда, если у тебя сейчас стандартный говнокод вида "у пети 2 яблока, а у васи 5": while mysql_fetch_array и вот это вот все.

Если тебе будут впаривать SQL_CALC_FOUND_ROWS - не ведись, это заведомо медленнее, чем count(*) и все равно 2 запроса.

Покупаете 1 роутер, 48 портовый свитч (желательно управляемый) и необходимое количество точек доступа. Так же, судя по вашему вопросу, нужно будет нанять специалиста который всё это дело настроит и подключит.

Что бы не тормозило - не стоит показывать 500 div на странице. Стоит подумать о виртуализации. Показывать только то, что помещается в экран.

мне говорят надо переделать, перестановкой элементов, а не заменой всего блока новым

возможно есть причины для этого. Но мне кажется 1 вставка куда быстрее.

Лакуны в автоинкрементном поле обычно связаны с запросами на вставку, которые не были выполнены (запросы с ошибками выполнения, INSERT IGNORE, INSERT ... ON DUPLICATE KEY UPDATE). Перед запросом резервируется необходимое количество новых идентификаторов и счётчик в таблице увеличивается, если запрос не добавил строки, то выделенные ему номера пропадают.

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

ну разные есть методики некоторые используют название get как взять т.е. либо данные либо ошибка + методы с префиксом find где либо данные либо false.
А в вашем случае можно изощерятся как угодно типа findAll, findById, findByConditions и т. д.
PS прочитайте про ORM

1. Для поиска одной записи по ID было бы логичным и удобным реализовать отдельный метод, например какой нибудь findOne($id). Что касается метода getAll - что содержит массив Options? Набор параметров по которым необходимо выбирать записи? если да тогда передавать это массивом, не очень хорошая практика, лучше сделать какой-нибудь объект критерию. Да и само название $options не особо удачно...
2. Лучше называть подобные методы например find()

Немного о наболевшем:

В MVC нет экшенов. MVC работает следующим образом:
- Во вьюхе располагается модель (например "текстовое поле")
- Любые изменения в модели сразу же изменяют вью (изменяем текст в текстовом поле и этот текст визуализируется/рендерится)
- Контроллер подписывается на события вьюхи (например "изменение текста в текстовом поле") и выполняет какое-либо действие, в том числе изменяет модели (ну хз, например проверяет что длина не более 10 символов. Или другой пример. Контроллер подписывается на событие нажатия кнопки "delete" и удаляет текст из модели текстового поля, а модель сразу же перерисовывается, т.к. напрямую связана с представлением).



Всё это прекрасно видно на картинке, которая взята с вики: https://ru.wikipedia.org/wiki/Model-View-Controller

В вебе реализация MVC без сокетов не возможна физически (который, к слову, в районе 80х-90х годов назывался MVCE: Model-View-Controller-Editor, не суть). Большинство существующих решений - это вариации MVP (Laravel/Symfony/etc) с небольшими нюансами. Контроллер там называются контроллерами, а не презентером по принципу GRASP и никак не связан с MVC.

НО. Есть такая штука как коллективное мнение. Например, по правилам русского языка можно писать "парашут", а не "парашют" начиная с какого-то там 2010го года. Это теперь норма. Хз. Короче безграмотных неучей дохрена. И т.к. таких реально дохрена, кто не может отличить одно от другого и не быть неучем, то решили что назовём-ка мы это дело "MVC с пассивными моделями", потому что называть этот подход MVP слишком сложно, это же читать надо ещё, учиться, лучше будем терминами кидаться, подумают что умный.

Так вот, к чему я веду. Классический MVP в вебе неудобен (что можно увидеть на примерах первого Zend, Phalcon и прочих догматов), по-этому добавили прослойку в виде роутера, который говорит: "По адресу /users при GET запросе отправляйся мне вот в этот класс и выполни вот этот метод", например: "$router->get('/users', 'UserClass', 'action')". Сам метод, возвращает нужную вьюшку с данными и называется "экшен", а класс, который содержит набор этих самых "экшенов" называется "контроллер" или "презентер". Во вьюшке, с помощью читов (шаблонизатора) можно указать, например, какой хедер\футер (лайаут) использовать, какой тайтл и прочее. Таким образом мы получаем разные страницы по разным адресам с разными данными, с возможностью сохранить основное оформление и пересипользовать какие-то другие куски вьюшек.

1) название класса в множественном числе никто не делает. просто Log.
2) используй PSR-3 Logger Interface, а не городи велик.
3) конструкции типа

if($stmt->execute(array($text))){
      return true;
    }else{
      return false;
    }

можно всегда сократить до
return (bool)$stmt->execute(array($text));

Бегло посмотрев:
1. Зачем в классе объявлены публичные атрибуты id и text если они нигде не используются?
2. Вы везде используете $db->prepare, но локальная переменная $db не инициализирована. В этом коде Вы должны обращаться к атрибуту класса, т.е. $this->db->prepare
3. Зачем в каждом методе делать проверку эту проверку

if($stmt->execute(array($text))){
   return true;
}else{
   return false;
}

но какой в ней смысл если $stmt->execute и так возвращает boolean, проще написать просто
return $stmt->execute();
4. Да и вообще в случае возникновения ошибки лучше что бы метод не false возвращал а исключение бросал, а клиенты класса уже на него как-то реагировали
5. В методе getAll у параметра $id лучше поставить значение по умолчанию null

Есть класс базы данных. Статичный синглтон.

Синглтон это не очень хорошо ... почему - можно просто погуглить этому посвящено не мало материалов

Нужно ли при создании новых классов создавать свойство db protected и внутри класса работать с db->, а не в DB::

Ну тут все зависит от того как Вы будете передавать объект базы данных в конкретный экземпляр. Если будете например использовать какую-нибудь инъекцию зависимостей, тогда само собой нужно записывать объект базы в свойство класса. Если же Вы планируете в классах делать что-то типа такого $this->db = DB::getInstance() то особого профита это даст (кроме незначительного повышения читабельности кода), а вот количество используемой памяти увеличит (за счет выделения дополнительных ссылок на объект базы данных)

1. Советую зашифровать стандартными средствами mysql 5.7 все данные: инструкция по-шагам.
2. Весь функционал ЛК (включая авторизацию и т.д.), обработку и хранение всех важных данных - вынести на другой отдельный хостинг (как поддомен), к которому доступ будет только по API через AJAX-запросы с веб-страницы, открытой в браузере у клиента.

хостись за бугром.
1) для таких хостеров нет дела до твоей клиентской базы.
2) даже если кто-то где то из россии захочет получить данные - им просто их не выдадут. потому что и до российского законодательства за бугром нет дела.