Задать вопрос
Ответы пользователя по тегу PostgreSQL
  • Как маппить результат запроса бд в структуры со вложенностями Golang?

    - Я считаю, что свой кастомный маппер - это отличное решение. Чтобы быть уверенней, обязательно напишите тесты. Как unit, так и интеграционные, например, с помощью testcontainers.

    - Можете вместо pgx посмотреть в сторону sqlc. У него совершенно другой подход. Вы пишете запрос со всеми джойнами, а он вам автоматически генерирует код со всеми структурами и функциями. Правда, там по джойнам практически отсутствует документация, но уж погуглите.

    - Ну, и если совсем сложно... то... может одним глазком глянуть в сторону ORM? Я никому не расскажу...
    Ответ написан
    5 комментариев
  • Как добавить отношения "многие-ко-многим" между таблицами из разных баз данных?

    Если вы разделяете проект на микросервисы, но связываете при этом их данные, то вы просто делаете распределённый монолит. А когда вы ещё и базу разрываете на два куска, при этом пытаясь сохранить между ними традиционные связи, как внутри одной базы данных, то вы:
    1. Не решаете абсолютно ни одной из задач микросервисов, т к. сервисы остаются жёстко связанными. Всё можно было бы решить просто при помощи "Clean architecture", DDD и т.д.
    2. Вы добавляете себе невероятное количество головной боли, связанной с самой микросервисной архитектурой, но и плюс все прелести из п.1.
    3. И тогда нафига козе баян?

    - Микросервисы должны иметь полностью независимые базы данных
    - Все взаимодействия должны осуществляться исключительно по API (это мой ответ на ваш вопрос). Как только вы связываете схемы данных, вы теряете весь смысл микросервисов.
    - Вы должны обязательно реализовать распределенные транзакции. Вы должны сами писать код для таких транзакций. А вспомните, как приятно и просто делать транзакции в монолите с одной базой данных.
    - Взаимодействие между микросервисами должно осуществляться на базе строжайших контрактов, которые можно менять только после обсуждения со всеми людьми, разрабатывающими данные микросервисы. Вам неплохо было бы выдумать или позаимствовать какой-то фреймворк, где четко будут описаны общие и частные принципы общения микросервисов.
    - Вы должны обеспечить мониторинг всего и вся, оповещение об отказах и деградации микросервисов
    - Вы должны обеспечить распределенное логирование, чтобы уметь отслеживать даже, например, простые запросы между логами из нескольких независимых систем.
    - И т.д. и т.п.

    Оно вам надо?
    Ответ написан
    Комментировать
  • Есть ли готовая среда для работы с базой PostgreSQL через Веб?

    Ох, вот меня и ударило ностальгией по голове... 20 лет назад, где-то, делал то же самое. MS Access был тогда прекрасной штукой. Задача была такой же, и выбора не было. Я взял как раз свеженький PHP 5-й версии, и относительно быстро решил этот вопрос. И вам советую сделать так же.

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

    Поэтому, вам нужно знать магическое слово "CRUD" (Create, Remove, Update, Delete), и с этим словом выйти в интернет) В частности, можно ввести на YouTube что-то типа "crud за час", и вам выпадет огромный список видео. Там будут решения и на PHP, и на Python, и на других языках. Но PHP и Python - это то, что вам надо искать.

    Желаю вам всяческих успехов!

    P. S. Если не сможете в дизайн, закажите на фрилансе вёрстку ваших форм и списков за 20 копеек
    Ответ написан
    2 комментария
  • Как в goшном SOA сервисе работать с базой данных?

    Не знаю, какая у вас архитектура, но когда какая-то библиотека обрастает огромным количеством методов, то Go - это один из редких языков программирования, который, благодаря своей утиной типизации позволяет использовать шаблон проектирования "consumer interfaces", т.е. объявлять интерфейсы в месте, где они используются и включать в эти интерфейсы только те методы из огромной структуры базы данных, которые именно тут, на месте, и используются. Таким образом ваши интерфейсы будут минимальными, понятными, и искать их не придётся. Ну, и в добавок, старый добрый Dependency Injection решит массу наших проблем

    База данных:
    package db
    
    import "fmt"
    
    // Стуктура базы данных. Здесь нам даже и не нужно объявлять никаких интерфейсов
    type Service struct {
    	// ...
    }
    
    func NewDbService() (*Service, error) {
    	return &Service{}, nil
    }
    
    func (d *Service) CreateUser(username string, email string) {
    	fmt.Println(fmt.Sprintf("user %s with email %s is created", username, email))
    }
    
    func (d *Service) CreateProduct(name string) {
    	fmt.Println(fmt.Sprintf("product  %s is created", name))
    }


    Пользователь:
    package user
    
    // Тот самый интерфейс, который нам позволяет выбрать из структуры базы данных
    // только нужные нам здесь методы
    type dbUser interface {
    	CreateUser(username string, email string)
    }
    
    type Service struct {
    	db dbUser
    	// ...
    }
    
    func NewService(db dbUser) (*Service, error) {
    	return &Service{db}, nil
    }
    
    func (c *Service) New(username string, email string) {
    	c.db.CreateUser(username, email)
    }


    Товар:
    package product
    
    // Тот самый интерфейс, который нам позволяет выбрать из структуры базы данных
    // только нужные нам здесь методы
    type dbProduct interface {
    	CreateProduct(name string)
    }
    
    type Service struct {
    	db dbProduct
    	// ...
    }
    
    func NewService(db dbProduct) (*Service, error) {
    	return &Service{db}, nil
    }
    
    func (p *Service) New(name string) {
    	p.db.CreateProduct(name)
    }


    main.go
    package main
    
    import (
    	"test2/db"
    	"test2/product"
    	"test2/user"
    )
    
    func main() {
            // Инициализируем базу данных
    	dbService, _ := db.NewDbService()
            // Структура базы данных реализует интерфейс dbProduct, инжектим её
    	productService, _ := product.NewService(dbService)
            // Структура базы данных реализует интерфейс dbUser, инжектим её
    	userService, _ := user.NewService(dbService)
    
            // Пользуемся на здоровье...
    	userService.New("user1", "uswr1@example.com")
    	productService.New("product1")
    }
    Ответ написан
    Комментировать