Стоит ли хранить массив в бд?

Question

[Banny_Boom]

Пользователь должен ввести определенные ссылки(около 30 ссылок)
Как лучше хранить эти данные?
Сериализовать массив и записать в бд ?

Answer 1

[Сергей Протько]

Сериализовать массив и записать в бд ?

в postgresql есть нормальные массивы, можно использовать их.

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

Comments

[Banny_Boom]

Я стараюсь более менее стандартизировать данные, например потом будет нужно по быстрому перейти на другую СУБД..

[LittleFatNinja]

Banny_Boom: тогда сериализация

[Сергей Протько]

Banny_Boom: тип с православного postgre на богомерзский mysql? да ладно... единственное что может произойти с базой - введение nosql решений (эластика например) для ускорения поиска. И там тоже есть массивы. Да и миграцию чуть что написать не проблема.

Answer 2

[mr-molodoy]

Какую базу данных Вы используете?
Если структура данных не реляционная в проекте посмотрите в сторону mongodb.
MongoDB является документ-ориентированной базой данных, формат каждого документа коллекции представляет из себя расширенную спецификацию JSON.
Использование такого решения позволит Вам:
1. Не заморачиваться с сериализацией / десериализацией данных.
2. Предоставит возможность удобным способом получить, например, все записи у которых в массиве имеется или отсутствует та или иная ссылка.
3. Позволяет хранить структуру данных любой вложенности массивов и простой выборки из нее, а так же удобно производить обновление данных в коллекции.
4. Каждый документ строго не привязан к структуре к структуре коллекции, как, например, в реляционных бд, таких как MySQL (все строки обладают одинаковым набором данных (т.е нет возможности в одной таблице хранить некоторые записи с одним набором полей, а во второй с другим)). Может быть как плюсом так и минусом, все зависит от конкретных требований к архитектуре и непосредственно хранимых данных.

Comments

[Banny_Boom]

реляционная

[mr-molodoy]

Подумайте, насколько допустимо было бы использовать комбинирование?
Разумеется что для каждого отдельного поля таблицы создавать отдельные коллекции не разумно, например, создавать в mongo коллекцию `links`, для хранения ссылок указанных в профилях.
С другой же стороны хранить профили пользователей в mongo, отдельно от непосредственно аккаунта, хранящегося в том же MySQL, кажется более разумным.
Это гораздо удобнее в использовании и более правильно с точки зрения реализации, нежели хранение не сериализованных данных в бд, не поддерживающей такую возможность (иногда у Вас просто не будет возможности десериализовать данные, поскольку, например MySQL не уведомляя Вас просто обрежет сериализованную строку до размера установленного максимальным, на конкретно данное поле таблицы и как Вы понимаете получить массив в целости не получится обратно).
Однако описанный подход так же не без изъяна, получая более комфортную работу с данными конкретной записи, ввиду хранения самих данных в разных источниках у нас усложнится процесс формирования списков из нескольких записей.
Т.е если мы просто получим несколько записей из MySQL а после, в каждой итерации цикла будем подтягивать связанные данные записи из Mongo у Вас просядет производительность.
Придется ухищряться след. образом:

1. Формируем запрос на получение записей из MySQL.
2. Получаем записи из MySQL
3. Формируем список идентификаторов записей (если данные у нас сопоставляются по идентификатору),
4. Получаем все связанные документы из MongoDB одним запросом.
5. Объединяем данные из двух БД в один объект модели.