Александр Ме

Не используйте стрелочную функцию

В проекте потребовалось освободиться от СУБД вообще.

a ничо, что sqlite – СУБД?

Там же в настройках всё написано.



Первая галка - интервал бездействия, после которого все вкладки сохраняются. Если вы ничего не делаете в течение этого периода - программа сохранит данные.

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

Третья позволяет делать бэкап перед сохранением.

Четвертая синхронизирует изменения в файлах, сделанные другими программи при переключении в шторм, или на конкретную вкладку.

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

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

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

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

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

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

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

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

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

Можно. Получится ли у тебя — вопрос, на который ответ знаешь только ты.

Острожно и последовательно апгрейдишь на 5.2, 5.3, 5.4, 5.5, 5.6, 5.7, 5.8, 6.х, 7.х, 8.х, читая Release Notes и Upgrade Guide.

в PHP.ini эти фукнции были перечислены как заблокированные:

disable_functions = [тут удаляем]

Вы неправильно поняли гугл. Он имел в виду, что нужно минимизировать "игла в яйце, яйцо в зайце, заяц в утке, утка в шоке", то есть, например, когда у вас html-документ, в нём скрипт, подгружающий CSS, в CSS ссылка на файл со шрифтом (особенно круто, когда всё это на разных доменах, которые нужно резолвить и устанавливать с каждым по очереди HTTPS-хэндшейки).

Законен ли парсинг БД ФНС?

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

Поэтому парсите на здоровье, но не увлекайтесь отправкой запросов разом с тысячи хостов.

Почти у любого пакета под laravel есть основной файл пакета ServiceProvider, в котором указывается где искать view файлы, js,css, подключение фасадов и компонент. Скорее всего при установке этого пакеты вы у себя даже добавляли подключение нового ServiceProvider в список всех провайдеров. И возможно будет достаточно отнаследоваться от базового класса ServiceProvider внутри пакета, подключить свой отнаследованный класс вместо предлагаемого разработчиком и внести необходимые изменения в уже свой провайдер, поменяв необходимые зависимости.

Скачай GitHub Desktop. Тебе будет проще разобраться в нём, чем изучать что такое git.

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

человек вообще ни у чом не уиноват.
просто в компании не выстроены (или не правильно выстроены) бизнес-процессы.

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

<template>
    <v-data-table>
        <template v-for="(_, slot) of $slots" :slot="slot">
            <slot :name="slot"/>
        </template>

        <template v-for="(_, slot) of $scopedSlots" #[slot]="scope">
            <slot :name="slot" v-bind="scope"/>
        </template>
    </v-data-table>
</template>