Спасибо!

Привет, использую ENGINE = MongoDB(), получаю ошибку: Cannot authenticate in MongoDB, incorrect user or password (version 21.3.3.14 (official build))Cannot authenticate in MongoDB, incorrect user or password (version 21.3.3.14 (official build))21.3.3.14 (official build)). Читал что некоторые методы авторизации монги не подерживаются, но решить проблему пока не получилось. Есть какие-то варианты или рабочие примеры?

баньте ботов

Через конкатенацию строк можно

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

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

например, url запросов все разные.. моментально забивают словарь и он становится неэффективным.

кх для того и нужен, чтобы хранить события в сыром виде, так что одна многоколоночная таблица это нормально, главное чтобы типы данных хорошо подходили под сами данные (например, не используй Nullable без необходимости). а далее дело за правильным выбором ПК исходя из типовых запросов к таблице, тут сильно поможет статистика по запросам, если она есть. ну и data skipping index'ы - они также помогают ускорить отдельные виды запросов с WHERE, не покрываемые ПК.

словарь для URL-запросов точно не нужен, как зачастую и для других видов данных, только потеряешь на JOIN'ах

а сколько можно колонок делать? если например появился новый параметр просто альтером колонку добавлять нужного типа.. но все остальные поля тогда будут пустыми.. вот именно null получается?

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

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

т.е. записать пустую строку или 0 или другое дефолтное значение.. лучше чем null?

Оно само запишется, если колонка не подразумевает null.

да, потому что null является отдельным значением, не входящим в низлежащий машинный тип данных, и для его представления создается отдельное поле или структура (обычно СУБД ведут bitmap для null'ов, емнип и кх тоже)

понял, спасибо!!! сейчас сделаю )

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

а какое максимальное кол-во колонок допустимо?

понял

навскидку не скажу, поищи в документации