Как автоматически найти правильную схему для хранения данных в базе данных PostgreSQL?

Question

У меня есть приложение C # WinForms, которое импортирует продажи, содержащиеся в файле фиксированной ширины, и сохраняет их в некоторых таблицах.Таблицы имеют одинаковую структуру, но расположены в разных схемах внутри базы данных.

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

Для лучшего примера,скажем, у меня есть таблица «Клиенты» в главной схеме и несколько схем (по одной для каждого региона моей страны) с таблицей продаж в каждой.Я использую идентификатор клиента каждой продажи, чтобы найти правильную схему для его хранения.

Мне нужно оптимизировать этот процесс, сделать его быстрее.Я профилировал приложение, и эти два запроса являются наиболее трудоемкими шагами.Я думаю, что выполнение одной команды внутри моего приложения и оставление работы по поиску правильной схемы для базы данных поможет.

Я хочу добиться чего-то вроде этого:

INSERT INTO 
    (SELECT clients.schema_name FROM main.clients WHERE client_id = @client_id).sales 
    (client_id, qty, value) 
VALUES 
    (@client_id, @qty, @value)

Очевидно, что это нене работает.Я не знаю много о SQL, только основы, но я думаю, что это невозможно сделать в одной команде, я думаю, мне нужна хранимая процедура для этого.

Я хотел бы услышать некоторые указанияили даже лучшие решения для этого (если это не связано с изменением структуры базы данных).

Answer 1

Ваша база данных повреждена, и избегание проблемы, скорее всего, не будет стоить этого в долгосрочной перспективе.Если вам интересно, нетрудно указать на проблемы с удобством использования таких схем.

Тем не менее, вы, вероятно, кэшируете client_id -> schema_name в своем коде C # и избегаете большинства запросов для получения этой информации.

Вы также можете написать SP, чтобы сделать это, но ему, вероятно, придется прибегнуть к построению динамических SQL-запросов или подобному хаку, который сам по себе может быть довольно медленным.