Flying

Нет. Разработка прекращена 7 лет назад.

Мне в свое время помогла проработка всех шаблонов проектирования из трех источников: "Head First Design Patterns"+refactoring.guru+designpatternsphp.readthedocs.io. Каждый шаблон разбирала и пыталась понять, почему здесь нужен паттерн, а не процедурный код, обернутый в один класс. Еще помогла книга по чистой архитектуре, но она зашла уже после паттернов. Просто важно полностью для себя понять, почему эти подходы до сих пор существуют и находить для себя два-три примера, потому что один-единственный пример для изучения может быть однобоким и даже неправильным.
Также эти книги и темы помогают вылечиться от трудностей решения задач на фреймворках, потому что наконец-то начинаешь видеть всю структуру и взаимодействия модулей и классов, а не просто примеры из документации натягиваешь на бизнес-требования)

Чисто теоретически в системе можно зарегистрировать любой URL-протокол (в windows).
Ассоциировать его с любым приложением, которое будет выполнять нужные вам действия (например запускать другие программы)

Так, телеграм при установке регистрирует протокол tg://, скайп – skype://.

Например, регистрируете протокол execprogam://, ассоциируете его со своей самописной программой или скриптом и делаете на web-странице ссылки вида execprogram://calc.exe

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

Поэтому, если вам решение требуется для внутреннего использования, для себя, это подходящий вариант.

return $this->createQueryBuilder('p')
    ->join(View::class, 'v', 'WITH', 'p.title = v.post')
    ->where('v.views > 0')
    ->getQuery()
    ->getResult()
;

phpstorm для основной разработки, любой редактор под руками (vsc, atom, sublime, nano, vim...) для посмотреть/быстрых маленьких правок.

сервер: все (за редким исключением) ставлю из пакетов, затем допиливаю ручками.

phpmyadmin/аналоги–для–других–баз последний раз видел году в 2010. с тех пор использую либо консоль, либо гуевые тулзы (для удаленного доступа через ssh/http–тунель).

докеры, вагранты, "идентичное проду окружение", "сборки – гавно" – это все типичный булшит и базвордс.
иногда перечисленное реально нужно и полезно (сам пользую где надо), но далеко не всегда/везде и не всем.

разрабатываете в одиночку – вообще пофигу на чем, лишь бы вас устраивало и было вам удобно.
разрабатываете в команде – пока ваш код запускается у других участников (что не проблема, если понимать что делаешь/особенности языка под разные платформы/следование принятым соглашениям), всем плевать на чем вы его у себя крутите. хоть стоя в лыжах в гамаке и на утюге.

Стоит.

1. Работу с request используют высокоуровневые вещи вроде контроллеров, поэтому использовать их в своих сервисах не стоит. Ваш сервис это по сути слой связи приложения и вашего кода. Поэтому правильней всего переложить данные из request в какую-то DTO например из патерна CQRS это может быть Command(), Query()

2. Даже когда вам потребуется передавать Request в какие-то свои классы, то лучше для этого использовать PSR интерфейсы. Тогда ваш Request будет фреймворконезависимым. .

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

Иногда бывает, что некоторые сегменты сети физически отделены от интернет, т.е. используется отдельная кабельная сеть и отдельные коммутаторы никак не связанные с интернет ни через шлюз ни через что-то другое.

С удаленными офисами связь предпочтительно делать не через интернет, а на базе какого-то оператора связи (или нескольких) формировать собственную корпоративную сеть. Трафик в такой сети передается через ВПН в шифрованном виде. Если какие-то удаленные офисы невозможно подключить к корпоративной сети, то используют интернет + ВПН. ВПН по уму должен строится с использованием сертифицированных средств.

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

Отключить целевой комп от интернета. А еще лучше - если уж такая паранойя - и из розетки выдернуть. По другому - никак.

https://symfony.com/doc/current/bundles.html

Избавляйся от ... where fld like '%...%' это самые плохие по скорости запросы, хотя не всегда это возможно без увеличения размера базы, вообще полнотекстовый поиск можно отдавать на откуп стороннему приложению (это может расширить возможности фильтрации), считай это еще одной формой индекса, хотя лучше данные по другому хранить. Я встречал ситуации когда в varchar хранили значения справочника из десятка значений, но делали по нему like %% что грузило базу прилично, когда как сделать простой комбобокс на порядок эффективнее и удобнее - поиск по подстроке лучше по справочнику делать на клиенте.

Без индексов скорее всего никуда, если в запросе идет фильтрация по полю, то если не создать на него индекс, этот запрос и будет создавать нагрузку

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

Частный случай прогноза, не делать select ... limit ... на каждую страницу, а при смене фильтра запрашивать весь диапазон, но только идентификаторы, сохранив их либо в таблице на сервере либо на бакэенде, генерирующим запросы вида select ... id in (...), последнее если количество записей не больше тысяч. Кстати именно постраничная навигация с прогруженным списком id самая шустрая

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

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

p.s. диск на сервере hdd или ssd? если не хватает денег на большой ssd, настрой маленький ssd как кеш к медленному hdd (linux bcache), даже когда данные полностью не влезают в кеш, это дает заметный прирост, потому что hdd начинает менее случайно двигаться, плюс добавляется буферизация записи (данные записываются на ssd и лежат там пока hdd не освободится), так же дает эффект ускорения записи вынос журнала файловой системы (если ext4) на ssd (требуется пара гигабайт от силы).

Осторожно, если высокие требования к надежности хранения, кеширующий ssd в режиме записи лучше пусть будет хотя бы raid1, так как иначе при смерти ssd починить данные, размазанные по диску и кешу будет очень сложно. Для кеша только для чтения это не так критично (при смерти ssd сервер просто упадет, не убивая данные).

Но мне больше нравится резервирование на лету (настроить онлайн репликацию, пусть и на слабый, бакап сервер)

Не хочется ругаться, но вопрос очень бессвязный и в нем перемешаны реальные проблемы с нелепыми фантазиями.

И проблема тут не в незнании как работать с большими базами данных, а в неумении работать с БД в целом.

Про идею "всем индекс не поставишь" надо сразу забыть. Там где индекс нужен, он должен стоять без вариантов. Другое дело что тупо натыкать индексов по всем полям, по которым идёт поиск - это тоже глупость. Индекс в запросе может использоваться только один, и индексы по второму-третьему полю уже будут бесполезны. Надо анализировать запросы и, возможно, делать составные индексы.

Детсадовский запрос вида like '%...%' - это отдельный ужас. Надо смотреть на полнотекстовый поиск. А лучше вообще его избегать. На крайний случай использовать внешние поисковые сервисы типа эластика. И только не говори что этот лайк у тебя идёт по полю типа джейсон или "через запятую"

Но самый конечно кошмар - это select distinct для фильтров. То есть неумение проектировать бд на самом базовом уровне, непонимание самых начальных принципов реляционных бд, нормализации. Вот с этих принципов и надо начать. В потом уже хвататься за большие объемы. Очевидно, что поля по которым ты собрался делать "distinct" - это должны быть отдельные таблицы, от которых в основной таблице будет просто id. поле размером в 4 байта.

Непонятно, откуда взялись фантазии про гигабайтные индексы, кстати. Большая часть полей в нормальной бд - это не больше десятка байт. То есть индекс - это десятки мегабайт, а не "гигабайты".

В общем, куда лучше бы смотрелись здесь не абстрактные рассуждения про большие объёмы, а конкретный запрос, который "отваливается". С обязательным результатом EXPLAIN

А ответ на абстрактный вопрос "как работать с большими объемами" очень простой: точно так же, как с небольшими. Реляционные бд изначально проектировались под большие размеры. То есть надо просто уметь работать с бд. Читать про реляционную модель, нормализацию, индексы, оптимизацию запросов.

Конкретно для грида надо смотреть в сторону Эластика/Сфинкса. В смысле чтобы не только для полнотекстового поиска, а чтобы все фильтры, которые есть выборке, были забиты в поисковый индекс. И все выборки - через поисковый сервис, а не через прямой запрос к базе

Писать в базу время в UTC будет проще всего.
Нерекомендуемой альтернативной будет хранить время-дату в БД вместе с тайм зоной.

Вне зависимости от добровольности пожертвования необходимо вести бухгалтерию и платить налоги. Поскольку заводить на левых людей счета вы не можете то вам придётся получать деньги на свой счёт и за это платить подоходный налог. А после этого вам придётся как-то перечислять этим людям деньги и им ещё придётся платить налог. Если вы хотите зарабатывать то будет брать комиссию, например. В итоге смысла в такой платформе мало очень)