Akina

а что делать с реляционной бд

А ничего. НЕ хранить ежедневные итоги. Только приходы и уходы. И самая первая запись - только приход (начальный баланс), если начинаем не с пустой кассы. А сумму с накоплением считаем непосредственно в запросе, в тот момент, когда потребовался отчёт.

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

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

Без промежуточных? Расстояние - в пределах домена коллизий.
Однако даже в таком случае расчёт времени невозможен. Например, оно может увеличиться (и сильно), если перестраивается RSTP.

Если принять такую формулировку:

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

то запрос на получение "первичных" товаров будет такой:

WITH cte AS (
    SELECT t1.cat_id, RANK() OVER (ORDER BY COUNT(t2.cat_id) DESC) rnk
    FROM user_to_cat t1
    JOIN user_to_cat t2 ON t1.user_id = t2.user_id
                       AND t1.cat_id <> t2.cat_id
    GROUP BY 1
    )
SELECT category.code
FROM cte
JOIN category ON category.id = cte.cat_id
WHERE rnk = 1

На данных из fiddle запрос даст 2 товара - orange и pear, оба они участвуют в 6 парах, тогда как apple участвуют в 4, а lemon в 2 парах.

Мне нужно найти запись на который у пользователя где у пользователя 1 накопится допустим 30 баллов, это запись id=5.

WITH cte AS (
    SELECT *, SUM(point) OVER (ORDER BY point_lifetime) cum_sum
    FROM tablename
    WHERE user_id = 1 --   у пользователя 1 
    )
SELECT *
FROM cte
WHERE cum_sum >= 30   --   накопится 30 баллов
ORDER BY point_lifetime LIMIT 1;

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

SELECT id, MIN(type) type
FROM t1
WHERE type IN (1, 2)
GROUP BY id

Обычный подход - тупо:

Количество(Склад Номер Х) = ВсегоТовара * НомерСклада / ВсегоСкладов - Количество(Склады Номер 1 .. Х-1)

Т.е. если, как в вопросе, три склада и 5 товаров:

Склад 1: количество = 5 * 1 / 3 - 0 = 1,666 = 2 штуки
Склад 2: количество = 5 * 2 / 3 - 2 = 1,333 = 1 штука
Склад 3: количество = 5 * 3 / 3 - (2 + 1) = 1,666 = 2 штуки

$amount = 5;
$num = 3;

for($used = 0, $i = 1; $i <= $num; $i++) {
  $used += ($current = round($amount * $i / $num - $used));
  echo("$i: $current\n");
}

https://phpize.online/sql/mysql57/undefined/php/ph...

насколько оптимально такое решение?

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

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

Актуализация данных таблицы (точнее, её полный пересчёт) выполняется из триггерной процедуры на каждое событие изменения любой из используемых в запросе таблиц, если изменение связано с вашей системой (заодно можно выпилить оттуда не связанные с приложением записи). Поскольку работа по изменению указанных данных достаточно редкая по сравнению с запросами на получение данных, такая схема может дать определённый профит. Однако, поскольку процесс предусматривает полную очистку таблицы и заполнение её с нуля, следует избегать интерференции со стороны двух конкурентных процессов изменения. Для полной гарантии любые изменения следует проводить в изолирующей транзакции.

Хотя как по мне, следует отделить систему безопасности Постгресса от авторизации в приложении. Мнение по данному вопросу от Everything_is_bad в комментарии - это не сарказм, а весьма правильное замечание.

Документация на странице 7 утверждает, что девайс поддерживает полный набор виланов, все 4096 штук.

чтобы ничего не двигать не редактировать

Нет, нельзя. Ширина колонки и высота строки - это именно атрибут колонки/строки. А не прямоугольного диапазона ячеек, в который выполнится вставка. Так что двигать - придётся.

Всё остальное (шрифты, цвета, заливка, выравнивание и пр.) должно копироваться нормально. При условии, что задано явно, а не используется дефолтная настройка. И при условии, что диапазон назначения заранее настроен на тип данных текстовый. Иначе преобразований некоторых значений в даты, выравнивание чисел по правому краю и прочих прелестей не избежать...

PS. Можно эту таблицу вставлять не как значения ячеек, а как объект Документ MS Word. Вот тогда точно ничего не уплывёт.

Ну вообще-то хранение изображений в полях базы данных считается антипаттерном... а по сути - это вообще худшее из возможных решений.

Наилучшее решение - файлы хранятся в FileTables либо FILESTREAM, а в таблице лежат ссылки на них. Что приятно - при этом не надо распыляться с безопасностью, за ней следит SQL Server.

Сравнение параметров для хранения больших двоичных...

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

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

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

Мой компьютер - ПКМ - Управление - Общие папки - Общие ресурсы - нужный ресурс - ПКМ - Свойства - Разрешения для общего ресурса

Заодно проверьте в локальных политиках, разрешен ли доступ из сети с пустым паролем (у юзеров пароли же не установлены, верно?). И не запрещён ли кому вообще доступ из сети.

LIKE в принципе не пригоден для указанной операции. Это чисто текстовый оператор. В частности, он безусловно применяет к обоим операндам регистронезависимый collation - в этих условиях сравнение БИНАРНЫХ строк способно давать весьма неожиданные эффекты.

Если надо работать именно с бинарными строками - всё плохо. В MySQL нет нормальных функций для работы с ними.

Для решения задачи рекомендую преобразовать бинарную строку в шестнадцатеричное представление, укоротить до 40-символьного (что соответствует 20-байтовому бинарному значению), преобразовать обратно, и сравнить.

WHERE CONV(LEFT(HEX('$entered_hash'), 40), 16, 10) = correct_hash

К тому же такое условие SARGable.

PS. В выражении

WHERE '{value1}' = '{value2}' OR '{value1}' LIKE '{value2}%'

первое условие заведомо лишнее (ведь если оно выполняется, то и второе тоже выполняется).

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

То есть какие-то дополнительные преобразования, изменяющие тип данных, выполняет PHP уже после того, как он получил ответ от MySQL. Или не PHP, а коннектор, который PHP использует для доступа к MySQL. Но в любом случае это происходит уже на стороне клиента.

Предположу, что эмуляция - процесс двусторонний. То есть не только на пути "туда", но и на обратном пути. Что при дополнительной обработке, которую требует настройка PDO::ATTR_EMULATE_PREPARES => true, корёжит тип данных.

На всякий случай проверьте, не вызывает ли изменение этого флага корректировки других флагов. В частности, PDO::ATTR_STRINGIFY_FETCHES.