ᴀᴋ
До этого юзал nosql и там прекрасно работалось с массивами у полей объектов
Size: a a a
2021 January 05
VG
лично мне проще массивом, если я правильно ситуацию представил (если речь про языки, значений врядли будет много в каждой строке)
ᴀᴋ
m2m — many-to-many.
Со списком подписчиков группы в виде массива на вас сразу обрушатся небесные кары. Например, вы останетесь без внешних ключей. Юзера удалили, а он до сих пор подписан на какую-то группу.
С языками попроще, так как они торчат сбоку, очень редко меняются и основном разве что добавляются.
Со списком подписчиков группы в виде массива на вас сразу обрушатся небесные кары. Например, вы останетесь без внешних ключей. Юзера удалили, а он до сих пор подписан на какую-то группу.
С языками попроще, так как они торчат сбоку, очень редко меняются и основном разве что добавляются.
А, теперь уже точно понял, спасибо). Ну то есть опять же зависит от ситуации, но в идеале предпочтение лучше отдавать именно отдельным таблицам ?
am
До этого юзал nosql и там прекрасно работалось с массивами у полей объектов
Оставь грехи своих денормализаций за дверью и войди в сияющие врата реляционного рая, сын мой. В смысле, ты можешь и в PostgreSQL использовать NoSQL-подходы, благо все инструменты завезли. Но на фиг они сдались — одна головная боль от них.
VY
За всю жизнь никогда не видел применения массивов на практике, кроме как для подсовывания в запрос с ANY.
Но гром не грянет, если вы эти языки сделаете массивом и пойдете спать.
Делать отдельную таблицу «правильнее», только она у вас уже денормализована. Делайте languages (id, name) и m2m с users.
Но гром не грянет, если вы эти языки сделаете массивом и пойдете спать.
Делать отдельную таблицу «правильнее», только она у вас уже денормализована. Делайте languages (id, name) и m2m с users.
через массивы можно делать column-storage-для-бедных, временами очень выручает
ᴀᴋ
лично мне проще массивом, если я правильно ситуацию представил (если речь про языки, значений врядли будет много в каждой строке)
Ну условно там будет по пять строк в массиве у каждого юзера
VY
Всем привет!
Что можете сказать касательно использования массивов на практике ? Допустим список языков пользователя хранить лучше в массиве или делать отдельную таблицу с (id, user_id, language)?
Что можете сказать касательно использования массивов на практике ? Допустим список языков пользователя хранить лучше в массиве или делать отдельную таблицу с (id, user_id, language)?
может вам
CREATE TYPE AS ENUM нужен?am
может вам
CREATE TYPE AS ENUM нужен?А какая разница? Все равно массив. ENUM — это ж такая строка для экономии байтиков.
ᴀᴋ
Оставь грехи своих денормализаций за дверью и войди в сияющие врата реляционного рая, сын мой. В смысле, ты можешь и в PostgreSQL использовать NoSQL-подходы, благо все инструменты завезли. Но на фиг они сдались — одна головная боль от них.
А тебя понял, спасибо)
ᴀᴋ
может вам
CREATE TYPE AS ENUM нужен?А в чем принципиальная разница ?
VY
А какая разница? Все равно массив. ENUM — это ж такая строка для экономии байтиков.
это число на самом деле, с доступом по строке.
VY
А в чем принципиальная разница ?
а покажите схему (из 2-х таблиц?), в которой используется такой вот массив для ограничения
ВГ
Всем привет!
Что можете сказать касательно использования массивов на практике ? Допустим список языков пользователя хранить лучше в массиве или делать отдельную таблицу с (id, user_id, language)?
Что можете сказать касательно использования массивов на практике ? Допустим список языков пользователя хранить лучше в массиве или делать отдельную таблицу с (id, user_id, language)?
массивы норм.
am
А, теперь уже точно понял, спасибо). Ну то есть опять же зависит от ситуации, но в идеале предпочтение лучше отдавать именно отдельным таблицам ?
Ну вот гляди. Выбирает у тебя пользователь языки. А где их список (полный) хранится? В коде. А нафиг они там в коде? Сделай таблицу languages, пусть там хранятся. И пользователю будешь показывать все содержимое таблицы languages при выборе. А еще тетя-админ твоей революционной социальный сети сможет сама добавлять языки, просто добавляя новую строчку в languages, а не дергать тебя каждый раз, когда на свете появляется новая народность. Круто? Круто. Делай отдельную таблицу, как деды завещали.
ВГ
Ну вот гляди. Выбирает у тебя пользователь языки. А где их список (полный) хранится? В коде. А нафиг они там в коде? Сделай таблицу languages, пусть там хранятся. И пользователю будешь показывать все содержимое таблицы languages при выборе. А еще тетя-админ твоей революционной социальный сети сможет сама добавлять языки, просто добавляя новую строчку в languages, а не дергать тебя каждый раз, когда на свете появляется новая народность. Круто? Круто. Делай отдельную таблицу, как деды завещали.
ага, добавит она строку для нового языка, а там rtl, и переводов нет.
ᴀᴋ
Ну вот гляди. Выбирает у тебя пользователь языки. А где их список (полный) хранится? В коде. А нафиг они там в коде? Сделай таблицу languages, пусть там хранятся. И пользователю будешь показывать все содержимое таблицы languages при выборе. А еще тетя-админ твоей революционной социальный сети сможет сама добавлять языки, просто добавляя новую строчку в languages, а не дергать тебя каждый раз, когда на свете появляется новая народность. Круто? Круто. Делай отдельную таблицу, как деды завещали.
Только я не совсем тогда понимаю как связывать таблицу со списком языков, в которую тетя может добавить языки, и список языков юзера🤨
VY
сколько раз видел системы, где “а у нас нету ограничений в базе, для скорости. всё контролирует приложение”.
а потом ты туда залазишь — мама родная! дубликаты, подчинённые записии без родителей и прочие радости…
а потом ты туда залазишь — мама родная! дубликаты, подчинённые записии без родителей и прочие радости…
am
Только я не совсем тогда понимаю как связывать таблицу со списком языков, в которую тетя может добавить языки, и список языков юзера🤨
При помощи таблицы languages_users(language_id, user_id)
ВГ
сколько раз видел системы, где “а у нас нету ограничений в базе, для скорости. всё контролирует приложение”.
а потом ты туда залазишь — мама родная! дубликаты, подчинённые записии без родителей и прочие радости…
а потом ты туда залазишь — мама родная! дубликаты, подчинённые записии без родителей и прочие радости…
бывало и обратно - когда код для языка пользователя через тройной джойн доставался
VY
бывало и обратно - когда код для языка пользователя через тройной джойн доставался
зато:
- в базе была целостность
- это можно оптимизировать не потеряв целостности
- в базе была целостность
- это можно оптимизировать не потеряв целостности