Эффективность решения будет сильно зависеть от того как представлены исходные данные. По поводу pdf/docx. Очень важно что было первоисточником. Если doсx получет путем конверсии из pdf то нафиг он такой нужен. Лучше всегда брать то что оригинал. Меньше шума будет внутри файла.
Очень важно как представлены таблицы. Это текст? Или сканированные картинки? Тоже сильно вляет на оценку сложности.
Qubc, точных условий я не помню. Но они примерно такие-же как и в топике. На малых объемах данных - простые алгоритмы и стурктуры данных работают всегда лучше чем сложные.
Вообще TCP/IP так устроен что акт коммуникации двух хостов всегда проходит при полной известности двух адресов. Иначе протокол не работает. И тут есть мысль что жертва автора внезапно может стать и не жертвой а совсем даже наоборот. И я очень надеюсь что автор имеет хорошие тылы или прикрытие. Потому что жертва может прийти домой и постучать автору в дверь. А это согласитесь уже вообще не смешно.
Стоит ли вообще таким заниматься сидя с жертвой в одной стране?
rPman, ну да. Это только практика покажет. Собственно эволюция MongoDb, CouchDb, e.t.c идет от практики применения документов со слабой спецификацией полей. Если там будут какие-то реляционные операции над атрибутами - то она будет работать не очень быстро. Но если надо просто найти товар и показать его - то вполне себе пойдет.
Здесь нет идеального решения. Здесь - матрица компромиссов. Где-то чуть-чуть мы проиграли. Где-то выиграли.
Но и EAV - это не серебрянная пуля. Это просто теоретизированная концепция.
Wan-Derer, ну да. Идея с юзер-сервисом вполне себе здравая. Да.
Посмотри OAuth2 Authorization Server. Кажется он поддерживает технологию JWT-токенов. Это щас самый популярный протокол авторизации.
По поводу сложностей деплоя микросервисов. Да. Есть такая проблема. Но если сравнивать с монолитом то denial of service монолита более заметна для пользователей чем недоступность отдельного микро-сервиса. Ну и для микро-сервисов есть отдельная культура деплоя. CI/CD и оркестровка и всякие blue-green техники плавного деплоя.
Сама MySQL так не глючит. Но если есть какая-то схема балансировки - то запрос может прыгать между master-slaves и в описанной ситуации есть признкаки такого рандомного переключения.
Как фиксить. Я думаю никак. Надо просто собирать логи и отправлять хостеру запрос на техподдержку.
Поскольку все сведения касающиеся личности пользователя - это PII (Personally identifable) то все страны и государства такую информацию закрывают достаточно быстро. Можно поискать в телеграм-боте Глаз Бога (в основном по РФ, Казахстан), но его базы - достаточно тухлые. И информация там может быть 10-летней давности.\
Wan-Derer, хорошо я понял. У тебя стоит тег - Spring. Это очень хорошо.
В том смысле что это сужает круг поиска и говорит нам что использовать.
Нужно смотреть какие механизмы предлагает Spring и брать просто
готовые шаблоны из spring initilizer.
Тоесть - никакого волюнтаризма. Идем уже проверенным путем.
Вобщем можно посмотреть в Spring Security, Oauth2 (client/server), Azure Active Directory
Spring LDAP.
Saboteur, я пробовал телегу. Не мое вообще. Стена сообщений скролится быстро. В некоторых за сутки наматывает по тыщи сообщений. Невозможно ничего найти. Я мысль теряю.
Исходники крепить неудобно.
Топики... ну вроде были добавлены недавно. Но не все каналы их подключили.
Вобщем я понимаю пользу от мессенджеров и даже не спорю с ней. Но моя концентрация внимания там падает очень сильно.
С форматом qna я согласен. Я понимаю что это - только вопрос-ответ. Но в таком кейсе - идеальный ответчик это GPT. Ответ - молниеносный. Темы покрывает. Сссылки дает. Ходи. Читай. Зачем тогда наши ответы?
Drno, общая БД - это хорошо. Но противоречит микросервисной архитектуре. Если БД является единой точкой отказа - то зачем тогда вообще распил на микро-сервисы. Тогда уже проще их делать монолитом.
Там должна быть строка
Main-Class : your.main.class.is.Here