Реляционная модель данных для сопоставления хранилища данных Google - PullRequest
3 голосов
/ 09 августа 2011

Во-первых, я родом из RDBMS / SQL / C ++ / Java / Python, и я новичок
Gaelyk, Google API и хранилище данных Google.

Мне нравится моделировать (используя блок-схемы для кода и инструменты моделирования БД для базы данных)
прежде чем я кодировать.
В прошлом я активно использовал Эрвина для моделирования БД.

В Erwin я разработал логическую / физическую модель данных базы данных, которую я хотел бы
реализовать с помощью хранилища данных Google и Gaelyk с помощью Google AppEngine SDK.

Я хотел спроектировать макет данных, прежде чем что-то кодировать.
Моим дизайнерским инструментом был Erwin Data Modeler.

Когда я посмотрел на хранилище данных Google, я увидел, что там
нет никаких реляционных ограничений, и соединения выполняются через
Предложение WHERE: связывать переменные.

Как мне сопоставить мою существующую модель (с PK / FK, зависимыми объектами, тяжелыми реляционными ссылками) с хранилищем данных Google?

Существует ли инструмент моделирования, который позволит мне создавать хранилище данных Google?
Предполагается, что проект БД вытекает из шаблона Gaelyk MVC и прямого кодирования?
Я не привыкла к этому, так как я работаю в RDBMS, где вы интенсивно моделируете
и все хорошее приходит от хорошего реляционного дизайна.

Кроме того, перед написанием кода клиентского приложения базы данных на императивном языке (C ++, C, Java, Python),
Мне нравится писать псевдокод, НО в первую очередь идет дизайн БД (если приложение
имеет базу данных)

Я все делаю неправильно? Похоже, мне доступен набор инструментов
чтобы начать кодирование, но набор инструментов дизайна не существует.

Добавление:
Вот логическая модель, которую я пытаюсь отобразить Model

Как бы я отобразил круговые отношения
account - (1: m) - следующий - (m: 1) - follow_account_id - (1: 1) - account_id?

1 Ответ

9 голосов
/ 10 августа 2011

В общем, руководящий принцип хранилища данных App Engine - и всех нереляционных баз данных - «оптимизировать для чтения».Вкратце это означает денормализацию, денормализацию, денормализацию.В некоторых случаях это усложнит обновления - например, если вы сделаете свое имя пользователя первичным ключом таблицы учетных записей, а пользователь захочет изменить имена пользователей, - а в некоторых случаях потребуется дублирование данных, например, сохранение постоянных счетчиков.Тем не менее, все это имеет смысл, поскольку обеспечивает гораздо лучшую производительность и масштабируемость чтения, а в типичном веб-приложении число операций чтения превышает число записей в сотни раз.

В частности, если рассматривать вашу модель, она очень нормализована.даже больше, чем большинство моделей РСУБД.Некоторые предложения:

  • Сверните такие вещи, как 'user_name_id', в свою таблицу основных учетных записей.
  • Для таких вещей, как 'follow' ', используйте свойство list, если число людей, за которыми следует человек, составляетобычно маленький (<1000) или <a href="http://www.google.com/events/io/2009/sessions/BuildingScalableComplexApps.html" rel="noreferrer"> шаблон разветвления в противном случае.
  • Выберите подходящий первичный ключ для каждой таблицы, где это целесообразно, например, имя пользователя или адрес электронной почты, и используйте его в качестве ключаназвание.Это позволяет искать записи с помощью операций get вместо запросов, которые значительно быстрее.
  • Когда необходима таблица поиска, такая как «тип учетной записи», убедитесь, что внешний ключ достаточно описательный, вам нужно только искатьсоответствующая запись для административных действий.Лучше хранить небольшие, редко изменяющиеся детали, подобные этой, вне хранилища данных, чтобы к ним можно было получить мгновенный доступ.
  • Для таких вещей, как теги, используйте свойства списка, чтобы уменьшить количество раз, когда вам приходится искать связанные объекты, иупростить индексирование.

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

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

...