Мое чтение пока ограничено, но пока вот некоторые ключевые моменты, которые я определил для использования хранилища данных GAE:
- Это не реляционная база данных.
- Дублирование данных происходит по умолчанию в пространстве хранения.
- Нельзя «объединить» таблицы на уровне хранилища данных.
- Оптимизировано для чтения с менее частыми операциями записи.
Этиприведите меня к следующей модели данных для системы блогов:
Блоги имеют относительно известный набор «столбцов»: идентификатор, дату, автора, контент, рейтинг, теги.Хранилище данных допускает добавление дополнительных столбцов по желанию, но известно, что вероятность добавления дополнительных столбцов на лету будет редкой, поскольку для этого потребуется больше специализированного внутреннего кода, а также больше внимания всей системе блогов.
У блогов нет определенного количества комментариев и тегов.В традиционной реляционной структуре БД они отображаются через соединение.Поскольку это невозможно в GAE, я подумал о реализации следующего:
- Статьи -> ID, Автор, Дата, Название, Содержание, Рейтинг, Теги
- Комментарии ->Article_ID, Автор, Дата, Содержание, Рейтинг
- Теги -> Метка, идентификаторы статей
Пример:
Article- 1 - Администратор - 01.01.2011- Вопросы?- Ответы ... - 5 - вопросы, ответы, спекуляции, размышления 2 - Администратор - 01.05.2011 - Кто знает?- Не я!- 10 - вопросы
Комментарии- 1 - Джон Смит - 01.02.2011 - глупый, глупый, глупый .. - 0 1 - Джейн Доу - 01.03.2011 - умный, умный, умный ..- 5
Метки - вопросы - 1, 2 ответа - 1 спекуляции - 1 размышления - 1
Теперь это мои рассуждения.При просмотре блога вы делаете это по: дате, автору, тегу / теме, рейтингу, комментариям и т. Д. Дата, автор и рейтинг статичны и поэтому могут легко находиться в одной таблице вместе с рассматриваемой статьей.
Теги дублируются между тегами «таблица» и статьей «таблица» статьи, но согласованность здесь обрабатывается на уровне приложения, и теги остаются, чтобы исключить объединение на уровне приложения при отправке статей в средство просмотра.Таблица Теги используется для поиска по тегу.Затем список статей анализируется на уровне приложения, а затем он получает эти статьи с помощью вызова приложения.
То же самое произойдет и с комментариями.Объединение будет происходить на уровне приложения посредством дополнительного вызова метода, передающего извлеченный идентификатор статьи.
Теперь, почему я хочу обработать объединение на уровне приложения?Я думал о том, чтобы вставить все в каждую статью, добавлять комментарии по мере их создания, но подумал о временной сложности сортировки и поиска, когда блог попал в тысячи статей, а также об ограничениях по размеру возвратов, а незная, насколько большими могут стать статьи / комментарии.Я не проверял, но, думая о сложности времени, я начал делать вывод, что количество поисковых статей будет линейно увеличиваться до количества статей при попытке поиска этих статей по тегам.Я прав в этом, и является ли этот подход способом преодоления этого?Кроме того, в целом эта модель данных выглядит как способ правильно реализовать постоянное хранение данных в GAE?
Спасибо, пытаясь обернуть голову вокруг нее ...