ThunderCat

Не навешивать обработчики из html.
https://developer.mozilla.org/en-US/docs/Web/API/E...

Если устроит csv вмето xlsx, то достаточно select ... into outfile 'filename.csv'
И отдать потом файл.

Ох, какие секретные все, "картинки с описаниями", туману побольше напустить. Да напиши уже - продаем сковородки, или кошачий корм. Меньше усилий на напускание туману и больше на техническую проблему.

Я могу ошибаться, но из вашего туманного описания складывается впечателение, что вы сперва сверстали "списки картинок", потом понаделали под них отдельных страниц с подробностями, а теперь раздумываете не стоит ли выбросить это все, и переписать нормально, чтобы товары хранились в базе данных, и можно было и вывести списки этих товаров (ваши основные страницы) и страница с "описанимями" создавалась автоматически. Перешел юзер на страничку "example.com/item/123" и видит там товар с номером 123, его описание, форму заказа, и вот это все.
Кажется, мы тут изобрели интернет-магазин.

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

Сделать вместо этого зоопарка ОДНУ таблицу.

Ужасная новость, шок, сенсация: HTML и CSS - вообще не языки программирования.
И да, я первые свои странички сделал прочитав одну статью из журнала (2 стр. текста с иллюстрациями), так что готовиться пару лет чтобы написать первую строчку кода - не обязательно.

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

С js, c++ и другими языками программирования все немножко сложнее. Там надо больше думать головой, продумывать структуру программы, алгоритмы, вот это все. Конечно, "hello world" можно и с мизерной подготовкой написать, но вскоре обнаружите что база очень нужна, и нужна хорошая.

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

Получилось ли выучить иностранный язык, просто зазубрив слова? Или выяснилось что и слова надо запомнить и практиковаться много раз, чтобы как-то начало получаться?

Алгебру - достаточно ли просто зазубрить что такое + - * / %, чтобы решать все задачи, или приходится на практике решать кучу задач, чтобы научиться это делать быстро?

Программирование НИЧЕМ не отливается от любых других направлений. Нужно и зубрить теорию и заниматься практикой, нельзя делать что-то одно. И высчитывать процент - это зачем? каждый человек немного уникален, у каждого процент будет свой.

С тем же успехом можно было спросить "Какие сейчас тенденции в программировании?" Web-разработка - это настолько обширная область, что общие тенденции в ней вряд ли возможны. Если брать относительно узкую категорию "Клепание однообразных говносайтов для ИПшников" то да, агрессивный маркетинг 1С всё ещё держит битрикс на плаву.

В принципе можно.
Но может тогда лучше класс создать с необходимыми методами?

class fun1 {
  constructor(){
    // код...
    this.#fun2();
  }
  #fun2() {
    // код...
    this.#fun3();
  }
  #fun3() {
    // код...
    // вызов какой-то из вложенных функций
  }
  #fun4() {
    // код...
    // вызов какой-то из вложенных функций
  }
}

const f1 = new fun1();

Использовать action можно, можете хоть сотню форм на одной странице иметь, это не мешает никак.
POST предпочтительнее для форм, чем GET, некоторые типы данных вообще не получится отправить через GET.

пока не нашел, как их обрабатывать на стороне php

это шедевр. Вы могли бы написать эту фразу просто в гугл, без "пока не нашёл", и сразу найти
https://www.php.net/manual/ru/reserved.variables.p...

Собственно, так и делают.
Только вордообразный wysiwyg редактор прикручивают (CKEditor, TinyMCE и т д)

ну как вариант

.slick-slider:not(.slick-initialized) {
  opacity: 0;
}

По поводу смыслов. Обычно с БД работают сущностями (entities). Я не специалист в Node и я не знаю
как у вас принято. Кажется в новых ecma-спецификациях уже ввели понятие класса.

В данном коде идет проверка на то что email существует. Но полезный эффект - слабый.
Я-бы сразу возвращал сущность пользователя. Чтоб не бегать потом в базу еще
раз когда надо поискать имя или дату регистрации. Ну идея такая что
если вы уж пошли в базу (это сетевой round-trip) то постарайтесь
за этот трип собрать максимум информации.

Вот это более рационально

export const findUserEntityByEmail = async (
  email: string
): Promise<User> => {
  try {
    const users = await db
      .query('SELECT * FROM accounts WHERE email = $1', [email])

Тоже самое относится к выборкам множества строк по множеству ключей.
Лучше сделать 1 callback который вернет коллекцию чем для коллекции
ключей дергать один несчастный метод который по штучке что-то достает.

Еще важне - join. Если соединяете сущности - то соединяйте сразу в БД
без попыток соединять в приложении. Это кстати еще бонус к компетенции
в части ACID.

Тоесть идеальный вариант работы с БД - запросить пакетом всю информацию
что может потербоваться на ближайшие несколько секунд. Это рациональнее
чем потом что-то подтягивать.

<?php
$fmt = new IntlDateFormatter(
    'ru_RU',
    IntlDateFormatter::MEDIUM,
    IntlDateFormatter::NONE,
    'Europe/Moscow',
    IntlDateFormatter::GREGORIAN,
);
$date = new DateTimeImmutable('2021-5-1');
print $fmt->format($date);
// 01 мая 2021 г.

Но в mysql есть же json поля, что если построить нужное дерево в виде json

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

Кстати, ковыряние JSON руками... либо JSON не более сотни байт, либо ни разу не развлечение (если ты не мазохист, конечно).

Несколько мыслей.

1) У меня устойчивое дежа-вю. Периодически в топик заходят люди с именно этим вопросом. Разница только в количестве. Кому 1 млрд. Кому 10. Можно также поискать и слинковать эти вопросы в один большой вопрос.

2) MySQL который указан в тегах - нормально справляется с этой задачей. Он и не такое число строк
умеет хранить. И если взять MariaDb - там есть куча новых engines которые можно крутить для тюнинга
именно скорости чтения. Разумеется жертвуя чем-то другим. Транзакциями и записью например.

3) Непонятно что такое минимальное время? Если использовать дисковую БД типа MySQL то деградация времени
поиска будет примерно зависеть от логарифма количества строк. Тоесть деградация будет но очень медленно.
Для 10 млрд индекс по key будет содержать порядка 4-5 уровней BTree дерева. Тоесть дисковой системе
нужно будет сделать до 5 или до 6 рандомных чтений (если нужные данные лежат в таблице). Это достаточно
быстро для того чтобы моргнуть глазом за это время. Рандомное чтение любого блока из магнитного диска
класса SATA-3 занимает порядка 20 милисекунд. Тоесть для 5 уровней - это 100 милисекунд. Для дисков
класса SSD и это время можно уже считать меньше милисекунды. Точно я не знаю надо мерять.

Испортить это время может сетевой лаг который в данной задаче мы просто не учитываем. Считаем что сеть идеальна.

4) Непонятно зачем здесь указан Redis. Его задача не хранить 10 млрд а хранить только горячие
ключи по котороым идет очень частый доступ. Если автор хочет In-memory хранение - то время можно
еще сильнее улучшить. Его можно свести практически до нуля (я вангую несколько микро-секунд)
но придется прикупить планок памяти побольше и посчитать сколько памяти
надо для 10 млрд key/values неизвестной длины. Вообще крутить регулятор в направлении
микро-секунд нет особого смысла т.к. другие звенья вашего стека (приложение и сеть) могут
быть на порядки медленнее а это вообще нивелирует всю пользу от такой оптимизации.

Вот ваши сырники 62 кб. Можно ещё легче сделать без потери качества.
Подробности здесь