DevMan

Можно почитать вот это: https://dev.mysql.com/doc/refman/5.7/en/general-ta... создать tablespace на разных дисках и сгрупировать по ним таблицы так, чтобы равномерно использовать место и производительность дисков.

Очевидно, что никаким образом не используют для тестирования sqlite, если в реальности используется другой движок БД. Создавайте тестовую БД и тестируйте в ней.

Либо меняйте для тестового окружения драйвер и используйте исключительно механизмы миграций и ОРМ без сырых запросов (или проверяйте, что их синтаксис нормально понимает sqlite). Но это, не менее очевидно, связывание себя по рукам и ногам.

Выполняем программу:

1. Видим echo, значит нужно распечатать её аргумент(-ы в нашем случае, т.к. их два, указаны через запятую. echo - это и функция и языковая коснтрукция, можно вызвать со скобками, можно без, через запятую просто передаём аргументы, сколько хотим)
2. Начинаем смотреть, какие аргументы надо распечатать: 1 . print(2) и 3
3. Первый аргумент составной, требует доп. вычислений. Начинаем его вычислять:
4. Сначала конкатенируем строку "1" с РЕЗУЛЬТАТОМ ВЫПОЛНЕНИЯ ФУНКЦИИ print(2).
5. Чтобы получить результат функции, её надо выоплнить. Выполняем print(2) -> печатается двойка. Вот откуда у нас первый символ "2".
6. Результат выполнения функции print() всегда 1.

Returns 1, always.

7. Значит результатом конкатенации у нас будет "1" . "1" -> значит первый аргумент для печати = "11" Печатаем его, на экране у нас теперь 211.
8. Печатаем второй аргумент "3". Получилось 2113.

./balong_flash
./ показывает что надо запустить с текущей директории.
Если не запустит, тоchmod +x balong_flash

В чем недостатки такого решения?

Помимо отсутствия транзакционности в коде (о чём уже упоминали выше):

1) Нет ключа на thread_id (желательно foreign)
2) Типы в INT, вместо UNSIGNED INT
Т.к. это MySQL, судя по вопросу, то:
3) Нет указания на collation таблицы (желательно utf8mb4)
4) Нет указания на движок таблицы (транзакции есть только в InnoDB и их нет в ISAM, MyISAM, Archive, Memory, etc.)
5) Нет уникальности голосов (т.е. votes), как следствие - таблица денормализованная и подсчитывать так голоса - крайне глупо. В нормальном мире это делается отдельной таблицей с привязкой по comment_id и уникальным ключом на comment_id + user_id.
6) Так как это комментарии, то использование varchar(255) для поля text - глупо. Нужен TEXT или LONGTEXT.
7) Отсутствуют поля даты создания и редактирования, что в будущем не позволит строить статистические данные или расширять функционал (разрешать менять текст комментария только в течении 5ти минут, например). На это надо закладываться заранее.

Это что касается структуры таблицы. Теперь по коду:
8) Сервис-локация (класс App), вместо нормального DI - это жесть. Скрытые зависимости говорят о невозможности тестирования такого кода.
9) "Магическая" константа 'comment' говорит о том, что потом такой код нормально не отрефакторить. Т.е. переименовываешь внутри что-то, а потом получаешь кучу ошибок и придётся лазать по коду и везде выгребать этот "get('comment')". И не дай бог где-то они получаются как-то иначе. Работы ещё на пол дня.
10) Метод getById говорит о том, что сущность должна возвращаться всегда. Однако, может так случиться, что её по указанному id просто не найдётся. Как следствие - нет нормальной обработки ошибок.
11) Мутабельное поле votes у comment (т.е. имеется прямой доступ к нему). Это говорит о том, что сущность очень сильно связана с БД, а значит любой рефакторинг таблицы ведёт к полному перелопачиванию всего кода.
12) Нет обработки ошибок во время сохранения сущности.
13) Метод vote - не лучшее название. Оно переводится и как глагол "голосовать" и как существительное "голос", что может запутать. Я бы переименовал в addVote. Хотя и так тоже норм.

Это всё, что касается вопроса "в чём недостатки такого решения". Ответ - почти на каждой строчке косяк.

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