Кэширование данных API, я должен сериализовать данные в один столбец? Или другой подход?

Question

Я внедряю приложение Twitter, где приложение должно кэшировать данные пользователей, приходящих из Twitter.Было бы разумно сериализовать данные в столбец с именем data?Или, в моей модели User, я должен создать столбец для каждого поля, которое возвращается запросом API *1003*?

Чтение о (ActiveRecord :: Base) сериализации .

Если я воспользуюсь последним подходом, я получу много полей в моей модели User, и если API Twitter решит добавить или удалить поля в будущем, то нам придется обновить нашстолбцы в нашей базе данных соответственно.

Однако, одно преимущество, которое я могу придумать с этим подходом, состоит в том, что каждый столбец был сохранен в базе данных.Я мог бы сказать, поиск всех пользователей Twitter в зависимости от местоположения.Я также мог бы индексировать столбец location для более быстрых запросов.Как это можно сравнить с сериализованным подходом?

Один из них предложит: «Не ищите сериализованные данные, просто не делайте этого» * ​​1016 *.

Так что, я думаю,, У меня может быть два столбца: data (для сериализованных данных) и location, нет?

Но давайте добавим еще несколько поворотов:

1. Приложению необходимо отсортировать пользователей по зарегистрированной дате.Не с нашим приложением, а с Twitter.
2. Приложение должно иметь возможность поиска пользователей по экранному имени Twitter или идентификатору Twitter.
3. Приложение должно иметь возможность сортировать пользователей по подписчикам, друзьями количество статусов.

Означает ли это, мне нужно 8 столбцов в моей БД: data, location, twitter_created_at, twitter_screen_name, twitter_id, followers_count,friends_count и statuses_count?На этом этапе было бы все же лучше выбрать подход типа столбца смешивания или просто выделить каждое поле в отдельном столбце.

Сохраните ли вы данные, возвращенные из API, в один столбец:data, или сохранить каждое поле в своем соответствующем столбце, или иметь сочетание обоих (как описано выше)?

Ваши мысли будут оценены по достоинству.

Answer 1

Итак, допустим, что у вас есть таблица со следующими тремя столбцами:

user_id, api_field_name, api_field_value

В этой таблице вы можете добавить строку для каждого поля API, которое хотите сохранить.Например:

user_d     api_field_name        api_field_value
1          "meaning_of_life"     42
1          "swallow_type"        "africa"

Это означает, что у пользователя с номером 1 есть эти два пользовательских параметра, которые привязаны к API ... если API меняется позже, а "swallow_type" удаляется, вы можете избавиться отэтот ряд.Новые поля API можно добавлять на лету.

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

Это та точка, в которой я отказываюсь, чтобы избежать входящего зева от пуристов БД ...