какой синтаксис для добавления массива данных в базу данных, я нашел для postgresql: pg.Array
// "ins" is the SQL insert statement
ins := "INSERT INTO posts (title, tags) VALUES ($1, $2)"
// "tags" is the list of tags, as a string slice
tags := []string{"go", "goroutines", "queues"}
// the pq.Array function is the secret sauce
_, err = db.Exec(ins, "Job Queues in Go", pq.Array(tags))






Здесь я остановлюсь на паре моментов, которые в основном связаны с отсутствием ясности в вашем вопросе:
pq.Array используется для преобразования значений массива в безопасные списки в PostgreSQL, например следующий оператор:
db.Query(`SELECT * FROM t WHERE id = ANY($1)`, pq.Array([]int{235, 401}))
Где результирующий запрос:
SELECT * FROM t WHERE id = ANY(235, 401)
Это предназначено для того, чтобы помочь вам безопасно создавать значения запроса, не относящиеся к типам, из списков, а это не то, как вы используете его в своем вопросе.
Если вы просто пытаетесь упорядочить значение в список, разделенный запятыми, в столбце базы данных, то есть:
| title | tags |
|---------|----------------------|
| my post | go,goroutines,queues |
Вам не нужна специальная функция в драйвере SQL. Вам просто нужно создать значение и позволить подготовленному оператору сделать свое дело:
tags := []string{"go, goroutines, queues"}
q := "INSERT INTO posts (title, tags) VALUES ($1, $2)"
_, _ = db.Exec(q, "mypost", strings.Join(tags, ","))
Вы, вероятно, были бы даже лучше обслуживались, если бы использовали отношения в MySQL для выполнения того, что вы делаете:
posts| id | title |
|----|---------|
| 1 | my post |
tags
| id | tag |
|----|------------|
| 1 | go |
| 2 | goroutines |
| 3 | queues |
posts_tags
| posts_id | tags_id |
|----------|---------|
| 1 | 1 |
| 1 | 2 |
| 1 | 3 |
Это поможет вам сэкономить место, не сохраняя повторяющиеся данные, и избавит от необходимости понимать метод сериализации в базе данных (плюс, это то, что реляционные базы данных делать). Затем, когда вы выбираете таблицу, вы можете создать операторы JOIN для извлечения данных по мере необходимости. Я настоятельно рекомендую прочитать о многих отношениях в MySQL.
@MarkusWMahlberg Я полностью не согласен с этим утверждением. В наши дни диск дешевый, как и вычисления. Да, это слишком усложняет простую структуру данных, но я бы не подумал, что он будет создавать только приложение, которое содержит только эти функции. Если начать с передового опыта, то в конечном итоге вы сможете создать лучшее приложение. «Какие теги используют все» бесконечно сложнее ответить в предыдущем подходе.
Есть разница между вычислениями и производительностью. Вы можете сколько угодно масштабировать вычисления - если запрос дороже другого, это займет больше времени. А без надлежащих сценариев использования, которые это оправдывают, нет необходимости усложнять модель данных.
Эта модель данных чрезмерно нормализована и приносит в жертву высокую производительность (JOIN-операции дороже, чем просто чтение поля) для относительно дешевого дискового пространства. Учитывая сегодняшние цены на хранение, это плохой компромисс.