Вопрос Кто-то занимается/разбирается в Postresql?

[Jacob]

Ищу человека, который разбирается в этой бд и ее интеграции к API

 

[Sniper]

Вы наверное имели в виду PostgreSQL?
Какая задача? Связана с 1С сервером или нет?

 

[Jacob]

Вы наверное имели в виду PostgreSQL?
Какая задача? Связана с 1С сервером или нет?

Есть несколько баз данных. Они были в формате CSV, я их загрузил в постгри (создал 1 базу, отдельно 3 базы CSV загрузил в 3 таблицы). Мне нужно осуществлять по ним быстрый поиск. И базы будут добавляться.
Вот ищу решение, чтобы ответы объединялись в один ответ и выдавались. В иделае прикрутить API. А выдачу сделать в JSON.

Работа оплачиваемая. Сервер на удаленке.

 

[obscure]

1. что вы подразумеваете под аббревиатурой "API":
a) написать дополнение к postgres-у , пересобрать оный и заюзать новую функциональность.
b) изваять что-то, типа процедуры/функции, которая будет выполняться на штатной версии постгре
c) другое.

2. версия postgres-а

3. ответы на запросы можно заджойнить/транспонировать при выборе,
либо собрать 3 ответа(предварительно унифицировав выхлоп по результирующим полям) через "union all"
4. если исходя из пп.2 версия постгре не от 1784 года - там есть функции выдачи выхлопа в json,
но не развесистого, "как Бог на душу положит", а чтото, типа жсон_аррай.
т.е. массива упорядочных жсон данных(строк, типа)

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

 

[Jacob]

1. что вы подразумеваете под аббревиатурой "API":
a) написать дополнение к postgres-у , пересобрать оный и заюзать новую функциональность.
b) изваять что-то, типа процедуры/функции, которая будет выполняться на штатной версии постгре
c) другое.

2. версия postgres-а

3. ответы на запросы можно заджойнить/транспонировать при выборе,
либо собрать 3 ответа(предварительно унифицировав выхлоп по результирующим полям) через "union all"
4. если исходя из пп.2 версия постгре не от 1784 года - там есть функции выдачи выхлопа в json,
но не развесистого, "как Бог на душу положит", а чтото, типа жсон_аррай.
т.е. массива упорядочных жсон данных(строк, типа)

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

пока загружены только 2 таблицы. для тестов.

названия полей можно изменять, таблицы имели разделитель и загружены верно. в целом. версия постгре 16 (вроде бы последняя).

нужно, чтобы оно искало. там указаны данные ФИО, дата рождения (стандартно в каждой базе). Сделаны индексы по этим данным. Но добиться выдачи всех полей не могу.

Пример запроса: Иванов Иван Иванович 01.01.1990.
Он должен по таблицам поискать всех таких и выдать все значения, которые есть в таблице (не только фио и др, а все поля, со всех баз).

 

[obscure]

пока загружены только 2 таблицы. для тестов.

названия полей можно изменять, таблицы имели разделитель и загружены верно. в целом. версия постгре 16 (вроде бы последняя).

нужно, чтобы оно искало. там указаны данные ФИО, дата рождения (стандартно в каждой базе). Сделаны индексы по этим данным. Но добиться выдачи всех полей не могу.

Пример запроса: Иванов Иван Иванович 01.01.1990.
Он должен по таблицам поискать всех таких и выдать все значения, которые есть в таблице (не только фио и др, а все поля, со всех баз).

1.таблицы с сырыми данными - это стэйджинг(raw).
к ним обращаться - тратить зря время,
да и неудобно.
Это временные таблицы
для загрузки из источников(цсв, эксель, другие базы).
Их нужно транкейтить перед каждой загрузкой

2.
лучше сделать 1(одну!!!) "обогащённую/стандартизованную" (ods/dds) таблицу,
которая содержит
данные из всех трёх.
Загружать в неё строки по команде/событию/джобу.


тогда запрос на поиск будет проводиться только
в одном месте.

и индексы только по одной таблице.

осталось дело за малым:
а) понять чего(не как, а чего!) хочет аутор идеи
б) придумать структуру ods-слоя, удовлетворяющую требованиям к формату выходных данных.
+ доп поля для удобства и быстроты поиска
в) прикинуть сколько миллионов строк будет поступать на ods-слой в месяц.
Возможно придётся партицировать
г)
написать код, который будет чистить/грузить сырые данные в raw-слой.
и код, который будет грузить данные из raw в ods/dds .
т.е. - организовать etl-процесс.

а поиск и вывод данных - дело 135-е,
первый класс/вторая четверть.

з.ы.
с джобами у постгре проблемы, это не оракл и не мсскл.

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

з.з.ы
>>[Но добиться выдачи всех полей не могу.]
у "операторов эвм" - обычно оч.маленькие оклады.
поэтому они могут преспокойно вводить:
а) латинские буквы вместо русских
б) при копипасте из разных прог, в венде частенько происходит конвертация ucs16(8)=>32
и с виду "одинаковые" символы имеют абсолютно отличающиеся коды.
Особенно это заметно при применении точек и кирилицы.

З.З.З.Ы
делр не в постгре вообще.
тут м.б. любая база
Но постгре приколен своим расширенным набором типов и функций.
Если строк, по которым дет производиться поиск мало - вообще отлично.
а если сотни миллионов - нужно либо прикупать дисков на индексы.
Либо научиться часто и долго пить кофий.
Либо накапливать данные для отчёта в чём нить аналитическом.
кликхоусе, например.

 

[Jacob]

1.таблицы с сырыми данными - это стэйджинг(raw).
к ним обращаться - тратить зря время,
да и неудобно.
Это временные таблицы
для загрузки из источников(цсв, эксель, другие базы).
Их нужно транкейтить перед каждой загрузкой

2.
лучше сделать 1(одну!!!) "обогащённую/стандартизованную" (ods/dds) таблицу,
которая содержит
данные из всех трёх.
Загружать в неё строки по команде/событию/джобу.


тогда запрос на поиск будет проводиться только
в одном месте.

и индексы только по одной таблице.

осталось дело за малым:
а) понять чего(не как, а чего!) хочет аутор идеи
б) придумать структуру ods-слоя, удовлетворяющую требованиям к формату выходных данных.
+ доп поля для удобства и быстроты поиска
в) прикинуть сколько миллионов строк будет поступать на ods-слой в месяц.
Возможно придётся партицировать
г)
написать код, который будет чистить/грузить сырые данные в raw-слой.
и код, который будет грузить данные из raw в ods/dds .
т.е. - организовать etl-процесс.

а поиск и вывод данных - дело 135-е,
первый класс/вторая четверть.

з.ы.
с джобами у постгре проблемы, это не оракл и не мсскл.

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

з.з.ы
>>[Но добиться выдачи всех полей не могу.]
у "операторов эвм" - обычно оч.маленькие оклады.
поэтому они могут преспокойно вводить:
а) латинские буквы вместо русских
б) при копипасте из разных прог, в венде частенько происходит конвертация ucs16=>32
и с виду "одинаковые" символы имеют абсолютно отличающиеся коды.
Особенно это заметно при применении точек и кирилицы.

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

 

[obscure]

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

незачто.
главное не нарвитесь на "не слишком дорого, но по-быстрячку".
это дорого и долго(ошибки проектирования + переделки).
Хотя я уже расписал, вплоть до "бери и делай".

 

[Jacob]

проковырял сегодня gpt. хорошая штука. помогает неплохо.
пока настроил простенький апи. все мои нужные фрагменты он соединил в один отчет. это победа)
своими силами - самое главное. ну и жпт.

всем спасибо)