Под ваше описание программы подходит sql-запрос, где таблица с ситуациями, есть таблица с ключевыми словами, с внешним ключом из таблицы ситуаций. И по ключевым словам выбираем ситуации.
Здравствуйте, а где изменения хранятся? Не совсем очевидно на схеме отображено. В таблицах overvalue и liquidity идет вставка или обновление значений? Есть ли логирующие таблицы на overvalue и liquidity?
Я считаю, что для задач оптимизации нужно в первую очередь здравый смысл, во-вторую понимание планов запросов и структуры БД, и конечно же знание архитекруты и особенностей той конкретной СУБД(на уровне плохого админа) и не хилые аналитические способности. Проблемы не столь очевидны, по крайней мере я с такими не сталкивался с проблемами, где, к примеру, дописав хинт все становиться отлично, и решает знание, как функционирует БД(как происходит соединение наборов данных и больше об арсенале этой конкретной используемой БД) и практика.
В общем, смысл разбить есть:
-для правильности и нормальной формы
-OLAP-куб(нужна снежинка)
Опять же повторю, не обращая внимание на многие "ЕСЛИ" читать проще и быстрее с одной таблицы.
Индекс на sku попробуйте.
create INDEX index_name ON table_name ((column_name ->> 'sku'));
SELECT * FROM table_name WHERE (column_name ->> 'sku') = 735215;
Albert Kazan, https://chartio.com/resources/tutorials/left-and-r...
Чтобы были запросы идентичны надо первый запрос написать вот так:
SELECT d.id, d.author_id, d.msg, d.added_time, u.name AS author_name
FROM discussion_messages AS d, people AS u
WHERE u.id(+)=d.author_id AND d.discussion_id=?
Или поменять второй запрос на
SELECT d.id, d.author_id, d.msg, d.added_time, u.name AS author_name
FROM discussion_messages d
JOIN people u ON u.id=d.author_id
WHERE d.discussion_id=?
Одно из 2х.
Да в одной- так проще обслуживать. Если вы храните сам файл, то скорее всего таблица со временем разрастется, а доступ будет осуществляться по индексу в БД - это нормально. И только если бы были какие-то проблемы с выборкой из таблицы из-за размера и каких-то других проблем. я бы подумал о секционировании таблицы, архивировании, а также возможность выделения типа договора в отдельную таблицу и заменой его на внешний ключ для индексирования по типу договора и выносом ряда столбцов- вертикальное разделение. Методы и средства зависят от конкретной БД.
Зачем что-то усложнять и делать предварительную чрезмерную оптимизацию.
Просто добавляете внутренний селект. Т.е.:
select stringid, string_agg(val, ', ') as val from(
...
union all
select stringid, 'door4' as val from qualitytable where door4 = 'yes'
union all
...
) as dataset
group by stringid
string_agg остается в таком же виде.
Рад помочь!:-)