Двигатель гигантского корабля сломался и никто не смог починить, поэтому наняли инженера-механика с более чем 40-летним стажем. Он очень тщательно осмотрел двигатель сверху вниз. Увидев всё, инженер разгрузил сумку и достал маленький молоток. Он без проблем ударил по стратегическим узлам. Вскоре двигатель снова запустился. Двигатель отремонтирован! Через 7 дней инженер сказал, что общая стоимость ремонта огромного судна для предпринимателя составила $ 20.000. "Что?! - сказал судовладелец,- Ты почти ничего не сделал. Дайте нам подробный отчёт." Ответ прост: "Удар молотком: $ 2. Знать куда ударить, сколько и как ударить: $ 19.998." Важно ценить собственные знания и опыт... потому что это результат борьбы, переживаний и даже слёз. Если я делаю работу за 30 минут, это потому что я потратил 20 лет на то, чтобы научиться делать это за 30 минут. Ты должен мне года, а не минуты.
мы фильтруем только пользователей. Всё удалённые заказы останутся в выборке, потому что у них своё deleted_at. В результате запись пользователя без активности выпадет, а заказы удалённого пользователя по-прежнему попадут в отчёт.
вот, если рассматривать отзывы, как некое описание произошедших событий (человек как-то провзаимодействовал с чем-то или кем-то, произошли какие-то события, и он их как-то описывает), то вполне логично рассматривать таким же образом, например, новости.
вот есть некоторая новость - описание автором новости некоторых произошедших событий. предположим, в этой новости говориться об том, что "некоторая команда по бадминтону, с названием Ростовчанка вступила в какие-то отношения с другой командой, с названием Токовчанка". Вощем, произошла череда каких-то событий, не знаю, высказываний, ещё чего-то - каких-то взаимодействий между командам по бадминтону Ростовчанка и Токовчанка.
да, предположим в данном тексте про ничего другого, кроме этого не написано.
вот. в зависимости от того, за какую команду - Ростовчанка или Токовчанка - мы яростно болеем, вот эти описанные события будут для нас положительными или отрицательными. так или нет?
отсюда возникает вопрос: как вы предлагаете решать и решали бы такую задачу с помощью описанного с этой прекрасной статье подхода?
статья, кстати говоря, очень хорошая, но - где-то это я недавно слышал...а-а, на канале Савватеева. там какой-то талантливый школьник рассказывал точь-в-точь тоже самое.
(сам школьник имеет шанс далеко пойти, если попадет к нужным людям, и его не испортят торгаши), но остается вопрос - чья же это оригинальная идея? (или она уже, давно, не оригаинальная?)
мускул оптимизировал запрос и поменял операнды AND местами
не согласен я с формулировкой. не то, что бы он не оптимизировал и не поменял местами, сам по себе SQL — это декларация, а не буквальная пошаговая инструкция. такого же рода например XSLT: высокоуровневое описание того, чего надо сделать.
да чё там — даже в классических языках программирования, типа C/C++, может вмешаться оптимизатор и итоговый код (ассемблерный) получается несколько иным. (отсюда например сюрпризы в многопоточных процедурах). про СУБД и говорить нечего. план выполнения запроса зависит от: индексов (которые есть в таблицах), статистики и селективности по имеющимся индексам (а она может быть битая/не успетая перестоиться), холодного/горячего старта данного запроса (были ли недавно запросы по таблицам из запроса), ресурсов сервера, нагруженностью СУБД-сервера по другим БД (и по этой, но по другой части). дохрена вообщем от чего зависит)))
Хеш — это реализация ассоциативного массива, но так как она очень распространена из-за того что кушает меньше памяти, чем, например, красно-чёрные деревья...
она очень распространена из-за того что у неё сложность поиска и построения O(1), (хотя памяти действительно кушает меньше чем в т.ч. и красно-чёрные деревья).
а у красно-чёрные деревья сложность O(log(n)).
второе: красно-чёрные деревья строятся путем балансировки, а балансировка осуществляется путем сравнения ключей на «больше/меньше» меж собой, (в отличие от хэш-таблицы, где требуется вычислять свертку ключа в значение и уметь сравнивать ключи на «равно/не_равно»).
поэтому: красно-чёрные деревья — это про сортировку, про поддержание отсортированного порядка элементов, а хэш-таблица — не про сортировку, про почти максимально возможный быстрый доступ (быстрее только прямое обращение по индексу в массив).
её там изначально нет, всё остальное — спецэффекты конретных реализаций))
вроде вы утверждали, что у вас «Если же разместить вложенный селект в WHERE после других условий, через AND, то до него дело вообще не дойдёт...»
вот например sql-server: разумеется, от перемены местами условий в WHERE план запроса не меняется. по другому и быть не может.
ещё например в sql-server можно хинтами пытаться указывать тип джойнов, типа LOOP | HASH | MERGE.
а например в Оракле хинтами также можно влиять на план запроса путем указания используемого индекса.
типом джойнов и индекса(!) но не как не перестановкой условий в WHERE))
т.е. вы утверждаете, что от перемены местами условий в WHERE у вас движёк БД исполняет по разному запрос? стабильно? и это подтверждается разными планами запроса? может удивите, приведя пример своей практики?))
(помниться на одном форуме, один программист, пытался использовать некий спецэффект реализации хэш-таблицы в одном из яп/фреймворков, который заключался в сохранении порядка добавляемых сортированных элементов. ему пытались объяснить, что хэш-таблиц это не про сортировку, а он говорил — ну вот же, практика))
Если же разместить вложенный селект в WHERE после других условий, через AND, то до него дело вообще не дойдёт на записях отброшенных предыдущими условиями.
в общем случае это разумеется не верно, потому что: sql — декларативный язык программирования, в котором описывается ожидаемый результат, а не способ его получения. т.е. последовательность условий в WHERE не означает их такой же буквальный порядок их исполнения.
и насчет регистра:
вот если написано вот так — «г. москва ул. кржижановского» — то «кржижановского» это ну прям точно улица адреса (т.к. слово редкое и в словаре есть), если вот так — «московская область, деревня хуево-кукуево» или «деревня малые ямки» — тут уже вопрос адрес это или нет. вощем получается со словарным подходом надо ещё словарь доразмечать — что там ну прям точно адреса, а что не точно…
в общем случае вообще ничего неразрешимо))
именно вот этот dadata эти два случая обрабатывает одинаково:
«г. москва ул. Кржижановского 15-2-1
г. москва ул. Кржижановского 15/2/1»
правильно или не правильно, это другой вопрос, но одинаково. и для человека это вобщем тоже, одно и тоже.
чувствительно к регистру:
«г. москва ул. кржижановского 15-2-1»
и к разделителям:
«г. москва ул. Кржижановского 15-2-1
г. москва ул. Кржижановского 15/2/1»
ну да, это трудно, потому что задача «строить синтаксические деревья» представляет из себя кучу подзадач: определить части речи, с разрешением частеречной омонимии, разрешить морфологическую неоднозначность, определить синтаксические роли слов в предложении. и это всё только для правильно написанного текста. если текст с ошибками (а ошибки то могут быть как орфографические, так и грамматические — любые) их исправлять/учитывать, вообщем… такими задачами можно и нужно заниматься, не побоюсь этого слова, годами))
«мучаюсь очень сильными головными болями, иногда даже темнеет в глазах от боли». Слово «болями» является сущностью «боль». А вот слово «боли» в конце не является сущностью «боль» — это скорее условие при котором темнеет в глазах
по моему у вас изначально не совсем правильный подход решению.
думаю, что для решения подобных задач нужно решать общую задачу построения синтаксического графа/дерева предложения.
и не именно в области медицинской тематики, а вообще в языке, в данном случае русском.
плюс медицинская тематика добавит проблем с массой ошибок в написании: «фарингит/форингит/фаренгит/форенгит/..» — кто знает, как это пишется?))
странные ваши рассуждения.
тут не премия Оскар вручается, за сторание и прележание))
автор явно её заслуживает — упорства, судя по всему ему не занимать- это серьезно, буз иронии.
он это не отменят сложности и качества решения таких задач, что и вызывает вопросы: «а как вы то сделали?», «а как с этим поборолись?» и т.д.
если у вас "«Три себе лоб» при таком подходе определится неправильно", то это я понимаю как то, что у вас в Pullenti части речи определяются просто по словарю, _без_ учета контекста.
на мой взгяд это фундаментальный недостаток, не устранив который, просто не возможно замахиваться на Вильяма нашего Шекспира.
движок SDK Pullenti я так бегло видал.
похоже он хорошо рабирает адреса, всякие номера паспортов, документов и т.д.
на таких задачах правила работают хорошо, но вот работа с текстом, в часности русским…
у меня технический вопрос в связи с этим:
как вы определяете части речи? по языковой модели, просто по словарю или как? контекст учитывается?
«Г-но на входе — г-но на выходе»
— так у вас не пишет, что «Г-но на входе». не пишет как раз потому, что не понимает, где какая часть речи.
не понимая, где какая часть речи (более базовую задачу), нельзя решить более сложную задачу — понять, о чем текст (в вашем случае текст задачи) — семантический смысл, так?
не понимая семантический смысл текста как можно делить, в вашем случае матем. задачи, на какие-то типы, которые вы можете решить или нет?
и о какой точности может идти речь?
с таким же успехом можно говорить о точности набора обезьяной теста «войны и мир»)))
Двигатель гигантского корабля сломался и никто не смог починить, поэтому наняли инженера-механика с более чем 40-летним стажем. Он очень тщательно осмотрел двигатель сверху вниз. Увидев всё, инженер разгрузил сумку и достал маленький молоток. Он без проблем ударил по стратегическим узлам. Вскоре двигатель снова запустился. Двигатель отремонтирован! Через 7 дней инженер сказал, что общая стоимость ремонта огромного судна для предпринимателя составила $ 20.000. "Что?! - сказал судовладелец,- Ты почти ничего не сделал. Дайте нам подробный отчёт." Ответ прост: "Удар молотком: $ 2. Знать куда ударить, сколько и как ударить: $ 19.998." Важно ценить собственные знания и опыт... потому что это результат борьбы, переживаний и даже слёз. Если я делаю работу за 30 минут, это потому что я потратил 20 лет на то, чтобы научиться делать это за 30 минут. Ты должен мне года, а не минуты.
что у вас за странная СУБД такая, что этот запрос вам заказы удалённого пользователя?
вот, если рассматривать отзывы, как некое описание произошедших событий (человек как-то провзаимодействовал с чем-то или кем-то, произошли какие-то события, и он их как-то описывает), то вполне логично рассматривать таким же образом, например, новости.
вот есть некоторая новость - описание автором новости некоторых произошедших событий. предположим, в этой новости говориться об том, что "некоторая команда по бадминтону, с названием Ростовчанка вступила в какие-то отношения с другой командой, с названием Токовчанка". Вощем, произошла череда каких-то событий, не знаю, высказываний, ещё чего-то - каких-то взаимодействий между командам по бадминтону Ростовчанка и Токовчанка.
да, предположим в данном тексте про ничего другого, кроме этого не написано.
вот. в зависимости от того, за какую команду - Ростовчанка или Токовчанка - мы яростно болеем, вот эти описанные события будут для нас положительными или отрицательными. так или нет?
отсюда возникает вопрос: как вы предлагаете решать и решали бы такую задачу с помощью описанного с этой прекрасной статье подхода?
статья, кстати говоря, очень хорошая, но - где-то это я недавно слышал...а-а, на канале Савватеева. там какой-то талантливый школьник рассказывал точь-в-точь тоже самое.
(сам школьник имеет шанс далеко пойти, если попадет к нужным людям, и его не испортят торгаши), но остается вопрос - чья же это оригинальная идея? (или она уже, давно, не оригаинальная?)
согласен. действительно - факт, и действительно - занимательный))
с каких это пор https://ru.wikipedia.org/wiki/Теорема_Эйлера_(теория_чисел) является занимательным фактом?
не согласен я с формулировкой. не то, что бы он не оптимизировал и не поменял местами, сам по себе SQL — это декларация, а не буквальная пошаговая инструкция. такого же рода например XSLT: высокоуровневое описание того, чего надо сделать.
да чё там — даже в классических языках программирования, типа C/C++, может вмешаться оптимизатор и итоговый код (ассемблерный) получается несколько иным. (отсюда например сюрпризы в многопоточных процедурах). про СУБД и говорить нечего. план выполнения запроса зависит от: индексов (которые есть в таблицах), статистики и селективности по имеющимся индексам (а она может быть битая/не успетая перестоиться), холодного/горячего старта данного запроса (были ли недавно запросы по таблицам из запроса), ресурсов сервера, нагруженностью СУБД-сервера по другим БД (и по этой, но по другой части). дохрена вообщем от чего зависит)))
она очень распространена из-за того что у неё сложность поиска и построения O(1), (хотя памяти действительно кушает меньше чем в т.ч. и красно-чёрные деревья).
а у красно-чёрные деревья сложность O(log(n)).
второе: красно-чёрные деревья строятся путем балансировки, а балансировка осуществляется путем сравнения ключей на «больше/меньше» меж собой, (в отличие от хэш-таблицы, где требуется вычислять свертку ключа в значение и уметь сравнивать ключи на «равно/не_равно»).
поэтому: красно-чёрные деревья — это про сортировку, про поддержание отсортированного порядка элементов, а хэш-таблица — не про сортировку, про почти максимально возможный быстрый доступ (быстрее только прямое обращение по индексу в массив).
её там изначально нет, всё остальное — спецэффекты конретных реализаций))
вот например sql-server: разумеется, от перемены местами условий в WHERE план запроса не меняется. по другому и быть не может.
ещё например в sql-server можно хинтами пытаться указывать тип джойнов, типа LOOP | HASH | MERGE.
а например в Оракле хинтами также можно влиять на план запроса путем указания используемого индекса.
типом джойнов и индекса(!) но не как не перестановкой условий в WHERE))
(помниться на одном форуме, один программист, пытался использовать некий спецэффект реализации хэш-таблицы в одном из яп/фреймворков, который заключался в сохранении порядка добавляемых сортированных элементов. ему пытались объяснить, что хэш-таблиц это не про сортировку, а он говорил — ну вот же, практика))
в общем случае это разумеется не верно, потому что: sql — декларативный язык программирования, в котором описывается ожидаемый результат, а не способ его получения. т.е. последовательность условий в WHERE не означает их такой же буквальный порядок их исполнения.
вот если написано вот так — «г. москва ул. кржижановского» — то «кржижановского» это ну прям точно улица адреса (т.к. слово редкое и в словаре есть), если вот так — «московская область, деревня хуево-кукуево» или «деревня малые ямки» — тут уже вопрос адрес это или нет. вощем получается со словарным подходом надо ещё словарь доразмечать — что там ну прям точно адреса, а что не точно…
именно вот этот dadata эти два случая обрабатывает одинаково:
«г. москва ул. Кржижановского 15-2-1
г. москва ул. Кржижановского 15/2/1»
правильно или не правильно, это другой вопрос, но одинаково. и для человека это вобщем тоже, одно и тоже.
«г. москва ул. кржижановского 15-2-1»
и к разделителям:
«г. москва ул. Кржижановского 15-2-1
г. москва ул. Кржижановского 15/2/1»
по моему у вас изначально не совсем правильный подход решению.
думаю, что для решения подобных задач нужно решать общую задачу построения синтаксического графа/дерева предложения.
и не именно в области медицинской тематики, а вообще в языке, в данном случае русском.
плюс медицинская тематика добавит проблем с массой ошибок в написании: «фарингит/форингит/фаренгит/форенгит/..» — кто знает, как это пишется?))
тут не премия Оскар вручается, за сторание и прележание))
автор явно её заслуживает — упорства, судя по всему ему не занимать- это серьезно, буз иронии.
он это не отменят сложности и качества решения таких задач, что и вызывает вопросы: «а как вы то сделали?», «а как с этим поборолись?» и т.д.
на мой взгяд это фундаментальный недостаток, не устранив который, просто не возможно замахиваться на Вильяма нашего Шекспира.
похоже он хорошо рабирает адреса, всякие номера паспортов, документов и т.д.
на таких задачах правила работают хорошо, но вот работа с текстом, в часности русским…
у меня технический вопрос в связи с этим:
как вы определяете части речи? по языковой модели, просто по словарю или как? контекст учитывается?
— так у вас не пишет, что «Г-но на входе». не пишет как раз потому, что не понимает, где какая часть речи.
не понимая, где какая часть речи (более базовую задачу), нельзя решить более сложную задачу — понять, о чем текст (в вашем случае текст задачи) — семантический смысл, так?
не понимая семантический смысл текста как можно делить, в вашем случае матем. задачи, на какие-то типы, которые вы можете решить или нет?
и о какой точности может идти речь?
с таким же успехом можно говорить о точности набора обезьяной теста «войны и мир»)))