mayton2019

Можно попробовать механизм регулярок

SELECT ....... WHERE REGEXP_LIKE(tranz_acct , '.*(99449872|23424232).*')

но сравни производительность в обоих случаях. Обычно регулярки не могут использовать индекс.
Поэтому будет FULL_TABLE_SCAN. В случае с like выражениями у тебя есть шанс пойти
в план с INDEX_SCAN но нужно пересмотреть саму задачу. Откуда цифры.
И можно ли во всех кейсах выделить общий префикс например.

В конце 20-го века, когда Эдгар Кодд развивал свою реляционную теорию было очень
модно все данные нормализовывать для хранения их в БД. Это соотвествовало экономии
ресурсов (диски мерялись килобайтами и мегабайтами) и нормализация хорошо ложилась на
техно-стек. Все данные должны быть атомарны. И ты - плохой DBA и программист если
кладешь в ячейку что-то более комплексное чем просто атом.

В 2000х развитие веб и XML(XHTML/SGML, XSLT, XPath) дало толчок новым видам
хранения информации в виде markup languages. Появляются технологии семанического веба.
Мечтатели-теоретики создают RDF, OWL. Базы данных пытаются успеть втянуть в себя новые типы.
Oracle начинает поддерживать XML+Schema как тип данных в таблице. Браузер начинает
поддерживаеть трансформацию XML и обогащение его стилями. XML - моден. Его внедряют
везде где можно и где не нужно. Даже в конфигах Apache Http и в сборщике Maven.

Параллельно Дуглас Крокфорд работает над Java Scrip Obj Notation и создает лайтовый язык
для описания объектов и документов. Они - конкурируют с XML но JSON практически побеждает
в вебе, полностью захватывая веб протоколы (Ajax, WebSockets, e.t.c). И интеракцию с сервером.
JSON становится более популярный для REST. Многие БД тоже начинают поддерживать JSON.
Postgres даже делает бинарный JSON и добавляет спец-индексы для быстрого поиска атрибутов.
Узко-специализированные системы такие как Mongo изначально заточены на храннение JSON
информации.

BigData плавно проростает в 2007 (кажется) и где-то в 2014 (или позже) году фреймворк Spark начинает поддерживать DataFrames + Structured Types которые по сути являются зеркалом JSON. Фреймворк
позволяет грузить в бигдату JSON-lines датасеты, автоматически выводя схему.

Это - финал. Я считаю что после такой конвергенции в бигдату JSON получил путевку везде где только можно.
Сегодня вы можете без стыда использовать JSON везде в любых уровнях стека (даже в Redis) если
у вас хватает памяти и вы уже порешали вопросы бизнес-согласованности данных и умеете эти
данные инвалидировать и обновлять.

Если поискать анти-паттерны применения JSON в базах данных - то я-бы предложил такую метрику.
Если вы очень часто обновляете маленькое поле внутри большого JSON документа и это создает
сильные I/O нагрузки то скорее всего вам надо перепроектировать вашу БД как-то по другому
и вынести это поле во вне по отношению к документу

Я в самодельных билдерах запросов добавлял фейковый предикат 1=1 который всегда был. Тогда добавление новых предикатов делается проще. Вот как-то так.

def get_user(*, username: str = None, email: str = None, id: int = None, is_blocked: bool = None):
    SQL = "SELECT * FROM USERS {} LIMIT %s OFFSET %s WHERE 1=1 "
    more = []
    if username:
        more.append("AND username = '%s'" % username)
    if email:
        if any([username]):
            more.append("AND email = '%s'" % email)
    if id:
        if any([username, email]):
            more.append("AND id = '%s'" % id)

Я проверял этот код на валидность. Это лишь идея как сделать. Поэтому исправляй дальше сам.

Как в такой схеме реализуются связи?

Обычно в игровой логике избегают использования SQL систем из-за unpredictable времени
отклика. Тоесть если в финансовой системе вы можете подождать секунд 5 или минутку
обработки транзакций то внутри игры игрок быстро заскучает и выйдет из игры.

Поэтому в играх обычно используют NoSQL системы (наподобие RocksDb, Cassandra)
но в них доступ идет только по ключу. Key-Value и никакие JOINS не работают.

Если сильно хотят подружить игру с платежной системой - то заводят отдельный сервер
для денежных операций (он может быть под SQL БД) но события между игрой и платежной
системой гоняют по очередям (MQ) чтоб не было нигде блокирующих операций.

Поэтому твой вопрос по сути - это квест. Типа пойдешь на право - перформанс потреяшь
или пойдешь налево - вырастет денормализация и аномалии в БД.

Если это одноразовая задача то поищи UPPER(value) LIKE '% ET%'

Если искать надо будет много - то почитай про

CREATE VIRTUAL TABLE .............. USING FTS5 ........

Путей много. Можно завести 2 таблички. Одна для новых машин. Другая - для подержанных. Со
своими наборами пропертей. Тогда и индексы строить удобно.
И с точки зрения типизации этот подход верный. Если язык разработки (Python/PHP) различает
типы машин - то для каждого типа нужна отдельная табличка. Это в духе ORM.
Недостаток - надо делать union all двух таблиц если мы хотим делать поиск по общим пропертям.

Можно завести 1 табличку с полем типа JSON и свалить туда все проперти которые могут быть
опциональны для новых машин и для Б/У. Это делает схему более компактной. И поиск по основным
полям работает универсально. Для кастомных полей надо искать описание в MySQL языков работающих
с JSON (JSonPath) для того чтоб выбирать и фильтровать и индексировать их.

Можно поступить как в BigData. Свалить все проперти что есть в одну большую таблицу. Будет в ней
допустим 500 колонок. И большая часть из них - пустая. Заполняется null. Такая модель тоже работоспособна.
Но для человека наблюдающего глазами таблицу будет неудобно с ней работать. Особенно когда нужное
тебе поле находится где-то на 400х колонках и надо скроллить грид мышкой вправо чтоб хотя-бы прочитать
глазами значения. И эволюция такой схемы проходит тяжелее. Т.к. alter table обычно блокирует таблицу
от транзакций DML и нужен регламент что добавлять новую колонку.