OSINT-разведка: идентификация пользователя по заданной местности

Увлекательно конечно исследовать то что тебе подсовывают. Насколько помню результат вывода ограничивается 100 бедолагами у которых включена настройка. А вы пробовали так найти конкретного человека, зная точно его геолокацию? Например найти свой профиль?

Курица не птица, техпис не инженер

А почему вы считаете что ваши 6 пунктов есть объективная истина? Мне например было интересно читать про жизненную историю со всеми ее ошибками и граблями. А так, декларативно обличать кого-то... Напишите нам как правильно

Open Street Map — OSINT-инструмент для маркетологов

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

пока готовил статью - выполнил выборочный парсинг по отдельным регионам. Вот несколько примеров "не по документации"

{"name": "Кырсай", "site": "kyr-altay.ru", "tourism": "chalet"}
{"name": "Мазаев-Моторс", "shop": "car_repair", "site": "http://mazaev-club.ru/"}
{"name": "Flamingo Bar (Bandara Hotel)", "site": "https://www.phuketflamingo.com", "amenity": "bar"}
ну и т.д.

возможно это не самый популярный тег для указания сайта, но в запросе я его всет-таки учел

Open Street Map — OSINT-инструмент для маркетологов

Согласен, Ваш запрос выглядит приятней и читается проще

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

nw[~"^contact:.*|email|phone|.*site$"~"."]

потому что интересующая инфа может присутствовать в различных тегах, например информация по сайту может быть в тегах 'site', 'website', 'contact:website'

Ваш пример запроса этот кейс не учитывает. если не прав - поправьте меня

Индивидуальный цифровой отпечаток — реальность которая подкралась незаметно

На одном из скринов лендинга написано как подключить скрипт. так и ввел

src="https://dmp.one/sync"

прелесть  publicwww.com что он может искать по фрагментам кода html

Индивидуальный цифровой отпечаток — реальность которая подкралась незаметно

Спасибо, поправил

Распознавание, хранение и поиск лиц в базе данных

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

Пишем поиск семантически похожих текстов (или товаров) за полчаса на Go и Postgres (pgVector)

Зависимости от API как и от стоимости за OpenAI можно избежать, если использовать для генерации векторов одну из предобученных бесплатных моделей, например эту https://huggingface.co/cointegrated/rubert-tiny2. Основная проблема здесь в другом. Точность оценки сходства сильно снижается когда тексты существенно отличаются по количеству токенов. Так что от игрушечного примера до реального проекта этот кейс еще пилить и пилить. А так да, классная подмога FTSу

Как пишут SQL-запросы гуманитарии

Да схему нужно было поразвернутей приводить. Писали уже выше. Учту спасибо

Как пишут SQL-запросы гуманитарии

Не совсем так. Уникальна пара инн+Огрн

А одна почта может быть привязана к нескольким компаниям отсюда и jsonb

Как пишут SQL-запросы гуманитарии

Насчет структуры - согласен полностью. В полной мере прочувствовал что ее улучшение - отдельная задача. Что касается оконных функций - пробовал такой вариант - скорость выполнения не очень была. Спасибо за отзыв

Как пишут SQL-запросы гуманитарии

В тексте код запроса с конкретными параметрами для примера. При тестировании скорости запросы оборачивались в функции.

select * from company_stat_by_inn('0054803450334')

select * from company_stat_by_name('ржд')

Как пишут SQL-запросы гуманитарии

Насчет кеширования на уровне ОС сказать не могу, не знаю как postgres взаимодействует с ОС. Функция pgsql в который оборачивал запрос судя по документации при первом вызове формирует и кешируеет план запроса. Что касается изменения входных параметров (инн или названия компании) скрость выполнения зависела только от количества и вывода найденных строк. это по моим экспериментам

Как пишут SQL-запросы гуманитарии

Да спасибо. С точки зрения вычислений запросы работают корректно

Что касается конструкции финального запроса - наверное вы правы. Если подскажете как еще можно избавиться от дубликатов кроме дистинкта будет здорово

Затаскиваем sqlite в облачный Битрикс24

Возможно. Я завершил публикацию тем что выразил в ней свое мнение.

А начал с того, что sqlite рассматривается в качестве дополнительного хранилища данных в облачных версиях Б24.

Вы предлагаете json. Наверное на небольших объемах данных действительно лучше. Только сколько будет весить такой файл на 1 млн. записей? И как быстро он будет искать нужные данные?

За подсказки по sql спасибо, не знал, учту.

По итогу, видимо не сумел популярно разъяснить главную мысль. Кейс не по тонкости и выгоду использования sqlite в отдельно взятом кейсе. Речь про то, что sqlite можно эффективно использовать как альтернативное хранилище данных на любом облачном тарифе Битрикс24

Затаскиваем sqlite в облачный Битрикс24

проверил, не отфильтровывает