Разделить объект на несколько моделей или кодировать в JSON?

Question

извините, если вопрос звучит так странно, но я не знаю, как еще его сформулировать. По сути, в моем приложении будет куча объектов. Каждый объект имеет некоторую структуру поста / комментария, хотя уникальность в том, что он более или менее статичен, поэтому я считаю, что нет смысла помещать каждый отдельный пост и комментарий в мою базу данных, потому что это вызовет больше загрузка базы данных? Вместо этого я подумывал о том, чтобы поместить JSON-представление поста с его комментариями, таким образом вызывая только один доступ к базе данных на объект. Я бы тогда рендерил объект JSON в контроллере или представлении или что-то в этом роде. Это правильное решение?

Answer 1

Нет!

Вы теряете все возможности запрашивать эти данные без какой-либо выгоды, если вы не находитесь в массовом масштабе. Задача базы данных состоит в том, чтобы эффективно использовать это для вас, и если вы создадите правильные индексы и реализуете правильные стратегии кэширования, у вас не должно возникнуть проблем с загрузкой базы данных. Вы хотите заменить все достоинства Rails ORM своей собственной, безусловно, менее полезной версией в интересах увеличения скорости, подождите, прежде чем она понадобится.

Что если позже вы захотите сделать самый популярный виджет комментариев на боковой панели? Или вы хотите просмотреть комментарии, независимо от того, с каким постом они связаны, в таблице для модерации? Что если вы хотите, чтобы ваши данные были доступны для поиска?

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

Answer 2

Как правило, вы хотите использовать JSON и т.п. в качестве крайней меры.Хранение JSON в БД имеет смысл, если ваша информация не обязательно известна заранее.Это не замена для правильного моделирования данных и не выигрышная производительность.

Чтобы дать вам представление о том, как я рассматриваю его использование в проекте, в LedgerSMB мы хотим иметь консультантовотслеживать дополнительную информацию о некоторых объектах БД.Потому что мы не знаем, что это будет заранее, JSON имеет большой смысл.Мы не ожидаем, что будем искать по данным или поддерживать поиск по данным, но если бы мы это сделали, это можно было бы организовать с помощью plv8js.

Answer 3

Хотя это звучит неплохо, но я не думаю, что это будет работать в долгосрочной перспективе, думая о том, что произойдет, когда у вас будет много комментариев к вашим постам. Вам нужно будет получить длинную строку из базы данных, а затем добавить к ней новый комментарий и затем обновить его в данных. Это будет очень неэффективно по сравнению с простым добавлением еще одного комментария в таблицу.

Кроме того, просто подумайте, что произойдет, если в какой-то момент вам придется дать пользователю возможность обновить комментарий. Получить конкретный комментарий из этой длинной строки и затем обновить его будет кошмаром, не правда ли?