Как вы обрабатываете связи в Базе Данных в приложении на Go?

Question

[Dmitry Shnyrev]

В своем Web приложении на Go для работы с базой данных планирую использовать sqlx который позволяет мне данные из запроса положить сразу в структуру. Вот как запрос сделать и структуру все вроде понятно.
Но как "красиво" работать со связанными данными?

Например у меня есть таблицы Articles и Users. Articles ссылается на Users через UserId.

Чтобы мне вывести список статей с авторами. Выбираю с помощью JOIN. Вот тут загвоздка. Мне нужно под это делать отдельную структуру со всеми полями которые содержатся в двух таблицах (т.е. в общем случае под каждый запрос делать свою структуру). Или можно сделать 2 структуры (User и Article как делают с ORM) и как-то хитро данные разложить по этим двум структурам и их как-то связать.

Что можете посоветовать, или поделитесь ссылкой на какой пример?
Спасибо.

Answer 1

[Oleg Shevelev]

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

Ну или попробуйте дописать нужный механизм в sqlx, всё польза будет:)

P.S. Знаю что топик изрядно старый, просто новых нет:)

Comments

[Dmitry Shnyrev]

Спасибо за ответ. Топик действительно сильно устарел - go забросил уже как полгода и никак не могу вернуться, хотя в душе мечтаю об этом (трудовые будни поглотили)

[Oleg Shevelev]

Я потихоньку переписываю библиотеки под себя, под задачи. Версия 1.4 очень хорошая, версия 1.5 недавно вышла и обещает быть как минимум не хуже, а потенциально привлекательной и уж точно интересной в 1.6. Сложно найти другой язык программирования который смог бы сделать конкуренцию Golang'у и увеличивающееся количество его упоминаний, статей о нём и библиотек к нему это только подтверждают.
На чём сейчас пишите? Что пишите?:)

[Dmitry Shnyrev]

Основной заработок - программирование под CRM Salesforce + JS (Angular, Ractive) . Для себя пробовал Ruby, Python, Go и NodeJS. Пока из всего больше нравится Go. Но в последний год перешел в разряд ИП и времени на личные проекты совсем пропало. Надеюсь что когда-нибудь появится проект за пределами Salesforce и тогда однозначно выберу Go.
Хотя практически на уровне Go находится NodeJS (любовь к JS тянется давно из фронтенда), но организм никак не может привыкнуть к "слишком" асинхронной модели на стороне сервера.

[Oleg Shevelev]

У JS слишком "плохая" асинхронность для серверных задач, а уровень и качество кода системных библиотек node.js желает лучшего... многим это нравится потому что это JS... других причин я не вижу.

Answer 2

[Dmitry Shnyrev]

Пришел к такому варианту. Что можете сказать по этому поводу?

есть две структуры:

type User struct {
	Id  int
	Username  string 
}
type Article struct {
	Id  int   
	Title  string
	User  User
}

Достаю данные и укладываю в Article вот таким способом:

rows, _ := DB.Queryx(SELECT a.title as title, u.username FROM articles a LEFT JOIN users u ON a.user_id = u.id)
for rows.Next() {
	a := Article{}
	err = rows.Scan(&a.Title, &a.User.Username)
	glog.Infoln(aa)
}

Вроде работает, но все прелесть от sqlx пропала - структура заполняется стандартным Scan из database/sql вручную.

Comments

[Tyranron]

Для такой задачи делать JOIN, еще и LEFT JOIN - фу-фу-фу. Базу, вижу, Вам совсем не жалко!
Чем подряд 2 запроса не угодили? Сначала выбираем нужные статьи, собираем с них айдишники юзеров и выбираем потом по этим айдишникам нужных юзеров (а если у Ваш юзеры кешируются, то можно и из кеша дернуть). Для конечного юзера разница во времени отклика будет не ощутимой, а база под нагрузкой спасибо скажет за то, что не заставляете ее делать лишние накладные расходы на временные таблицы, а данные сразу по индексам дергаете простыми запросами.
И на Ваш sqlx такое дело ляжет так, как Вы хотели. Сначала заполняете map'у или slice Article'ов, потом вытаскиваете User'ов и раскидываете указатели на конкретного User'а конкретному Article'у.

[Dmitry Shnyrev]

Это отличный подход. Я так уже более 3 лет делаю в Salesforce :) просто потому что там нет JOIN. Но вот пришел в мир plain sql и как бы хочется делать "красиво". Как раз до этого пытался узнать у гугла что лучше - один join из 2 таблиц или 2 запроса отдельно. Почему-то все советуют join, а не заниматься сбором parent ids в коде для подготовки второго запроса. Мне тоже проще так делать (в смысле 2 запроса) на код ложиться вообще замечательно.
Спасибо за совет. Буду рыть в этом направлении.
Если не сложно, приведите пример когда все-таки join лучше чем 2 и более отдельных запроса.

[Tyranron]

Dmitry Shnyrev: иногда есть случаи, когда без JOIN'ов просто не обойтись или это слишком накладно. Например: у нас есть таблица комнат, каждая комната имеет один из трех цветов r/g/b и id (rooms: id, color) и есть таблица посещений этих комнат (visits: id, user_id, room_id, created_at). Задача: вывести последних 30 посещений пользователя с user_id=30 красных комнат (color=r). Этот кейс уже нельзя так просто раскатать в 2 запроса подряд.
Также, если нужно руками в базу сбегать, то лучше накатать один большой запрос и вывести себе все нужную информацию сразу, чем дергать частями. Или, если запрос выполняется гарантированно не часто (например cron'ом раз в столько-то минут), то можно его сделать сложнее, это не создаст какой-то ощутимой нагрузки на базу, а Вам ускорит дело и будет удобнее.

[Tyranron]

Dmitry Shnyrev: резюмируя: для разовых и гарантированно нечастых запросов JOIN'ы можно, для мест под нагрузкой - противопоказанно, но бывает что никуда не денешься особо.

И да, все сказанное мной относится в основном к MySQL, потому что он достаточно прямолинеен в таких вещах. Другие базы могут нашаманить чудесных оптимизаций всяких так, что и JOIN'ы шустрые и подзапросы не хуже, а то и быстрее JOIN'ов. Это уже надо вникать в особенности конкретной используемой базы.

[Dmitry Shnyrev]

@Tyranron спасибо за советы. Приму к руководству однозначно. По базам данных, по привычке из Rails использую Postgres. Почитаю что пишут про эту базу и сложные запросы.

[Dmitry Shnyrev]

@Tyranron, не могли бы прокомментировать мои результаты. С join и без join. Как-то без join совсем не очень красивы выглядит. Неужели такая вермишель кода и циклов выгоднее одного join?

c join:
(пример из самого вопроса)

с двумя запросами:
articles := []Article{}
err := DB.Select(&articles, "SELECT * FROM articles")
uIds := []string{}
for _, a := range articles {
uIds = append(uIds, strconv.Itoa(a.UserId))
}
users := []User{}
err = DB.Select(&users, "SELECT * FROM users WHERE id IN ("+strings.Join(uIds, ",")+")")
if err != nil {
glog.Fatalln(err)
}
usersMap := make(map[int]User)
for _, u := range users {
usersMap[u.Id] = u
}
for i, a := range articles {
articles[i].User = usersMap[a.UserId]
}

Может скиньте свой пример какой-нибудь?

[Tyranron]

Dmitry Shnyrev: Кому выгоднее? Базе - да, выгоднее. Приложению - нет, не выгоднее. Что легче отмасштабировать горизонтально, чтобы снять нагрузку - базу или приложение? Делаем выводы.

Своими примерами не поделюсь, так как мне пока хватало стандартного database/sql для моих задач и я не гнался за лаконичностью, а действовал по принципу "явное лучше неявного" (что, мне кажется, достаточно идеоматично для Go), дополнительно снабдив все это дело разухабистыми проверками ошибок, что в будущем сохранило много времени при дебаге. Но это совсем не то, что ищите Вы.

В принципе, ситуацию с 2мя запросами я не вижу как можно сильно не исправить к лучшему, разве что навести аккуратность и убрать лишнюю "вермишель" (пишу без проверок ошибок по Вашему примеру):

// вытягиваем статьи
articles := []Article{}
err := DB.Select(&articles, "SELECT * FROM articles")

// собираем id'шки
uids := []int{}
uidsToArticles := map[int][]Article{}
for _, a := range articles {
uids = append(uids, a.UserId)
uidsToArticles[a.UserId] = append(uidsToArticles[a.UserId], a.Id)
}

// вытягиваем пользователей
users := []User{}
err = DB.Select(&users, "SELECT * FROM users WHERE id IN (?"+strings.Repeat(",?")+")", uids...)

// раскидываем их по статьям
for _, u := range users {
for _, a := range uidsToArticles[u.Id] {
a.User = u
}
}

[Dmitry Shnyrev]

@Tyranron, спасибо за пример.
Отличная идея с uidsToArticles := map[int][]Article{} Действительно код стал лучше выглядеть.
Вот эта часть тоже заинтересовала - IN (?"+strings.Repeat(",?")+")", uids... По ходу изучения сталкивался с полярными мнениями на счет этого куска кода. Одни говорят, что надо переменные из array передавать через биндинг по одной (как у вас). Другие говорят что надо страивать прямо в запрос (как у меня) и мол это хоть и не безопасно, но быстрее. Я взял за основу первый вариант, потому что у меня Postgres, а там placeholders вида $1, $2, $3 ... и получается что вот эта часть strings.Repeat(",?") растягивается на цикл.
Спасибо за советы. Вы помогли пересмотреть мое отношение к процессу разработки на Go. Думаю дальше будет легче. Есть ли у вас еще какие-нибудь ресурсы в интернете с информацией по Go (может быть статьями) или другие сайты где вы предпочитаете общаться на тему Go, чтобы можно было пообщаться персонально? Toster хоть и хорош, но общения в комментариях к ответу как-то не очень выглядит :) Может быть какой форум?

[Tyranron]

Dmitry Shnyrev:
Встраивание в запрос - это совсем какая-то экономия на спичках. Более того - потенциально не безопасно, если у Вас строки. В третьих - потеряете преимущества prepared statements, которые для Go очень актуальны, ведь можно подготовить запрос чуть ли не при запуске приложения и потом гонять его сколько душе угодно (так что вопрос о производительности спорный). В четвертых - не для string'ов приходится чертыхаться с конвертированием в строки, что не всегда удобно и элегантно. Так что выгода достаточно сомнительна на самом то деле.
Что касается placeholder'ов вида $1, $2 - достаточно один раз написать вспомогательную функцию которая принимает число и возвращает сколько нужно placeholder'ов и использовать ее в проекте. По лаконичности будет даже лучше.

Я не сильно социальный человек и привык больше читать и вникать, нежели общаться. Конкретно по тематике Go могу посоветовать русскую golang google groups (https://groups.google.com/forum/#!forum/golang-ru ), ну и go nuts (https://groups.google.com/forum/#!forum/golang-nuts ), куда же без них. Если интересует общение лично со мной, стучитесь в скайп с тем же ником, что видите здесь.