Сергей Попов

mvps.net - 3 года - полет нормальный

я посоветую одно - это сменить руководителя дипломного проекта и тему диплома

Для полнотекстового поиска в MySQL есть специальные функции, но, в данном случае, лучше интегрировать готовую систему (поисковую машину):

• Sphinx
  
• Solr
  
• Elastic
  

Eloquent = Doctrine?)
Советую вам хоть немного разобраться что это такое, и какие паттерны реализованы в Доктрине, а какие в елоквенте.

Мне в Laravel понравилась свобода - то есть при желании я могу запросто напихать в шаблоны PHP-код и в запросы к базе - RAW-SQL и запихнуть эти запросы хоть в роутер))))

Пишите на чем угодно, все равно в помойку отправится, потому что подерживать такое никто не будет.
Фреймворк для того что вы хотите делать не нужен вообще.

А то мне сейчас нужно сайт-сообщество сделать, и я пока так и не нашел годный готовый опенсорсовый движок для этого на основе Laravel.

Опять же - вам не нужен фреймворк. Фреймворк это каркас для приложения которое вы будете писать.

Вы наслушались где-то про фреймворки, и теперь пытаетесь рассуждать о них даже не понимая что это такое и для чего они нужны.
Вам нужен готовый конструктор / CMS

Ну огромная же куча статей в интернете на эту тему, например: https://habr.com/ru/company/hexlet/blog/274675/

А тот вопрос что вы задаёте относится к проектированию API и тут уже придётся сломать об этот камень огромную тучу копий. Делайте как это будет удобнее использовать. С другой стороны одну из этих проблем решают OData, Protobuf\GData, RAML, GraphQL и прочие надстройки над REST.

Сюда, сюда жалуйся.
Мы все тут на них негодуем и горячо тебя поддерживаем. В аду им гореть!

Можно посмотреть на архитектуру CQRS + Event Sourcing. Вместо того, чтобы хранить состояние сущности, хранят произошедшие с ней события. Накатив эти события в порядке очереди на сущность всегда можно получить состояние сущности на любой момент времени.

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

Базы данных можно брать любые, хотя обычно для ReadModel используют стандартную реляционную или документоориентированную, а для WriteModel можно взять что-нибудь более специализированное, например event store, просто потому что все фишки реляционных субд для этой части приложения не требуются.

Можно посмотреть примеры реализации event sourcing https://github.com/prooph/event-sourcing

alfresco посмотрите

Нашел ответ на вопрос на странице помощи (Помощь → Регистрация):
Несколько организационных моментов:
- В любом из трёх случаев вам на почту придёт уведомление;
- Модерация может длиться от 1 минуты до 1 недели — наберитесь терпения;
- Причина отклонения статьи нигде не указывается, в службе поддержки спрашивать нет смысла;
- Исходные коды отклонённых статей мы не высылаем — храните резервные копии у себя.
UPDATE:
Действительно после почти недели (6 дней) ожидания я получил ответ на почту. Таким образом, максимальный срок модерации составляет неделю.

Однозначно дать ответ сколько необходимо оперативки не получится.
Т.к. всё зависит от того, как вы работает с данными.

Есть ли у вас есть большое кол-во не лимитрованных выборок?

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

Можно попробовать:

$html = strip_tags($myContent, '<h1><ul><li><p><img><iframe>');

select vehicle.id, vehicle.mileage, vehicleType.name
from vehicle join vehicleType
on vehicle.vehicleTypeId = vehicleType.id