Александр Ме

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

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

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

Детсадовский запрос вида 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>

Делайте геттер и там вычисляйте имя. Ну и соответственно возвращайте нужное свойство, а не строку, как сейчас.

Например так: https://jsfiddle.net/yarkov_aleksei/1ub0enxq/

Второй путь, однозначно.
Не занимайся ерундой. Без знания языка изучать фреймворки бессысленно.

https://medium.com/@taylorotwell/package-auto-disc...

Советую брать что-то готовое. Потому как если проект будет живой и работать, в любом случае будут вылезать те или иные косяки, недоработки и т.п.
Так что берите например тот же вукомерс, базовый набор и вперед.
По умолчанию ничего сложного, куча всего уже готово(интеграции и проч) легко кастомизируется. Это же можно сказать и про многие другие.
Либо вообще выбрать платформу вроде insales.
Писать свое не рекомендую. Тем более если условно простое. Больше смысла писать свой продукт под нечто большое, с уникальными требованиями и тп, на что потом будут готовы выделять ресурсы. А так будет просто мертворожденное решение и проблема у владельцев если нужно что-то допилить.

Вот здесь, например, делал когда-то такую вещь (блок "Этапы создания корпоративного сайта").



Идея, вкратце:

1. Элементы размещаете просто в сетку с помощью inline-block/float/flex/grid - как привычнее.
   
2. Родителю задаёте относительное позиционирование, в него помещаете абсолютный элемент на всю ширину/высоту с небольшим запасом, на котором будете рисовать SVG.
   
3. Как нарисуется - на js считаете ключевые точки (координаты), через которые нужно провести линии.
   
4. Динамически рисуете SVG по вашим ключевым точкам.
   О том, какие варианты вообще есть, можно почитать на MDN, например.
   Выглядеть это будет примерно так:
   
   
   
   В вашем случае рекомендую использовать кривые Безье. Здесь мне нужно было сделать полукруг, поэтому я использовал дуги, у вас же просто статичная величина закругления.
   
5. На ресайз окна считаете ключевые точки заново и перерисовываете SVG.
   
6. Опционально заморачиваетесь и добавляете сверху ещё один путь, который по скроллу будет "заполняться"
   

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

Готовых вариантов тут в общем-то вы вряд ли найдёте, нужно взять и разработать.
У меня была идея оформить это в какую-то библиотеку, но как и все остальные идеи - и ныне лежит в туду-листе на 60+ пунктов. :)