DC
2.
0000-00-00 00:00:00 отменили, теперь только 1970-01-013. вы забыли заалисить имя поля в MV
4. Поле в таблицы_1 nullable?
все это делается проще: assumeNotNull(`
PlannedTimeEnd`) as PlannedTimeEndSize: a a a
2021 March 07
D
1. нельзя проверять в JDBC.
2.
3. вы забыли заалисить имя поля в MV
4. Поле в таблицы_1 nullable?
все это делается проще: assumeNotNull(`
2.
3. вы забыли заалисить имя поля в MV
4. Поле в таблицы_1 nullable?
все это делается проще: assumeNotNull(`
круто, подошло! большое спасибо!
D
и за материал тоже спасибо
2021 March 08
S
всем привет, есть такая таблица Metric и делаю вот такой селект:
select * from Metric
where orderCreateDateTime = toDateTime(today())
order by eventDateTime;
вопрос: Нужно ли вставить в селекте в части order by (именно eventDateTime) если уже при создании таблицы указано в части order by таблицы ?
select * from Metric
where orderCreateDateTime = toDateTime(today())
order by eventDateTime;
вопрос: Нужно ли вставить в селекте в части order by (именно eventDateTime) если уже при создании таблицы указано в части order by таблицы ?
А
curl-м сначала добейтесь чтобы работало
Решение не помогло, 1 из 5 раз вылетает ошибка парсинга (( может есть еще какие-то варианты? 🙏🏽
M
всем привет, есть такая таблица Metric и делаю вот такой селект:
select * from Metric
where orderCreateDateTime = toDateTime(today())
order by eventDateTime;
вопрос: Нужно ли вставить в селекте в части order by (именно eventDateTime) если уже при создании таблицы указано в части order by таблицы ?
select * from Metric
where orderCreateDateTime = toDateTime(today())
order by eventDateTime;
вопрос: Нужно ли вставить в селекте в части order by (именно eventDateTime) если уже при создании таблицы указано в части order by таблицы ?
Зачем ?
S
Походу понял в чем проблема
ДБ
Решение не помогло, 1 из 5 раз вылетает ошибка парсинга (( может есть еще какие-то варианты? 🙏🏽
Скинь на pastebin пример curl-запроса
DC
всем привет, есть такая таблица Metric и делаю вот такой селект:
select * from Metric
where orderCreateDateTime = toDateTime(today())
order by eventDateTime;
вопрос: Нужно ли вставить в селекте в части order by (именно eventDateTime) если уже при создании таблицы указано в части order by таблицы ?
select * from Metric
where orderCreateDateTime = toDateTime(today())
order by eventDateTime;
вопрос: Нужно ли вставить в селекте в части order by (именно eventDateTime) если уже при создании таблицы указано в части order by таблицы ?
обязательно нужно.
постарайтесь постить поменьше ненужных картинок, этот create table вполне мог бы быть текстом
постарайтесь постить поменьше ненужных картинок, этот create table вполне мог бы быть текстом
DC
Решение не помогло, 1 из 5 раз вылетает ошибка парсинга (( может есть еще какие-то варианты? 🙏🏽
в смысле проблема с курл тоже воспроизводится?
S
обязательно нужно.
постарайтесь постить поменьше ненужных картинок, этот create table вполне мог бы быть текстом
постарайтесь постить поменьше ненужных картинок, этот create table вполне мог бы быть текстом
Спасибо, только дошло до меня что order by указанный в таблице это как индексы и не имеет отношение в сортировании (order by) при селекте.
Хорошо в след. раз все текстом буду писать.
Хорошо в след. раз все текстом буду писать.
Б
Привет! Нужен совет по организации таблицы: хочу хранить метаданные сообщений и морфологически разбор слов в них.
Морфологический разбор слова представлен в виде тегов (1 тэг —строка длиной в 4 символа, всего тегов 115, в разборе может присутствовать до 10).
Не совсем понятно, как быть: хранить в таблице записи сообщений и разбор слов в виде двумерного массива из слов и их тэгов, или писать в таблицу по одному слову и сделать для каждого тэга по отдельному столбцу.
Со вторым вариантом кажется легче будет искать что-то по тэгам, а с первым легче будет группировать данные по сообщениям. Нужно и то, и другое. Возможно я вообще не туда смотрю, и можно сделать иначе.
Есть у кого-нибудь идеи?
Морфологический разбор слова представлен в виде тегов (1 тэг —строка длиной в 4 символа, всего тегов 115, в разборе может присутствовать до 10).
Не совсем понятно, как быть: хранить в таблице записи сообщений и разбор слов в виде двумерного массива из слов и их тэгов, или писать в таблицу по одному слову и сделать для каждого тэга по отдельному столбцу.
Со вторым вариантом кажется легче будет искать что-то по тэгам, а с первым легче будет группировать данные по сообщениям. Нужно и то, и другое. Возможно я вообще не туда смотрю, и можно сделать иначе.
Есть у кого-нибудь идеи?
DT
Привет! Нужен совет по организации таблицы: хочу хранить метаданные сообщений и морфологически разбор слов в них.
Морфологический разбор слова представлен в виде тегов (1 тэг —строка длиной в 4 символа, всего тегов 115, в разборе может присутствовать до 10).
Не совсем понятно, как быть: хранить в таблице записи сообщений и разбор слов в виде двумерного массива из слов и их тэгов, или писать в таблицу по одному слову и сделать для каждого тэга по отдельному столбцу.
Со вторым вариантом кажется легче будет искать что-то по тэгам, а с первым легче будет группировать данные по сообщениям. Нужно и то, и другое. Возможно я вообще не туда смотрю, и можно сделать иначе.
Есть у кого-нибудь идеи?
Морфологический разбор слова представлен в виде тегов (1 тэг —строка длиной в 4 символа, всего тегов 115, в разборе может присутствовать до 10).
Не совсем понятно, как быть: хранить в таблице записи сообщений и разбор слов в виде двумерного массива из слов и их тэгов, или писать в таблицу по одному слову и сделать для каждого тэга по отдельному столбцу.
Со вторым вариантом кажется легче будет искать что-то по тэгам, а с первым легче будет группировать данные по сообщениям. Нужно и то, и другое. Возможно я вообще не туда смотрю, и можно сделать иначе.
Есть у кого-нибудь идеи?
Количество тегов может расти?
Б
Количество тегов может расти?
Теоретически, да
DT
Привет! Нужен совет по организации таблицы: хочу хранить метаданные сообщений и морфологически разбор слов в них.
Морфологический разбор слова представлен в виде тегов (1 тэг —строка длиной в 4 символа, всего тегов 115, в разборе может присутствовать до 10).
Не совсем понятно, как быть: хранить в таблице записи сообщений и разбор слов в виде двумерного массива из слов и их тэгов, или писать в таблицу по одному слову и сделать для каждого тэга по отдельному столбцу.
Со вторым вариантом кажется легче будет искать что-то по тэгам, а с первым легче будет группировать данные по сообщениям. Нужно и то, и другое. Возможно я вообще не туда смотрю, и можно сделать иначе.
Есть у кого-нибудь идеи?
Морфологический разбор слова представлен в виде тегов (1 тэг —строка длиной в 4 символа, всего тегов 115, в разборе может присутствовать до 10).
Не совсем понятно, как быть: хранить в таблице записи сообщений и разбор слов в виде двумерного массива из слов и их тэгов, или писать в таблицу по одному слову и сделать для каждого тэга по отдельному столбцу.
Со вторым вариантом кажется легче будет искать что-то по тэгам, а с первым легче будет группировать данные по сообщениям. Нужно и то, и другое. Возможно я вообще не туда смотрю, и можно сделать иначе.
Есть у кого-нибудь идеи?
есть залитые данные в таблице?
можно посчитать кол-во уникальных комбинаций тегов?
можно посчитать кол-во уникальных комбинаций тегов?
DT
Как еще один вариант можно сделать через доп таблицу как реверс индекс
Идея примерно такая: https://habr.com/ru/post/304602/
Идея примерно такая: https://habr.com/ru/post/304602/
Б
есть залитые данные в таблице?
можно посчитать кол-во уникальных комбинаций тегов?
можно посчитать кол-во уникальных комбинаций тегов?
5532 комбинации
DT
Сколько всего строк будет (в день, месяц)
Б
Сколько всего строк будет (в день, месяц)
К сожалению, не могу точно сказать. Минимум — от 10К сообщений в месяц