Как у вас не присоединяется?

Вы используете db.ReferenceProperty для связывания объектов, подробности и примеры см. В Google App Engine: ПРИСОЕДИНЯЙТЕСЬ "один ко многим".

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

Я имею в виду, зачем писать цикл? Это просто запускает одни и те же строки кода снова и снова! Не хватило одного раза? Это огромная трата!

Приведенные выше утверждения носят иронический характер.

Я хочу сказать, что запрос содержит соединение с целью: получить правильный ответ. Неэффективное или ненужное использование объединений - это, конечно, плохой дизайн, как и размещение инвариантного кода внутри цикла.

Избегание объединений в качестве общей политики - это пример преждевременная оптимизация. Если ваш подход к написанию эффективного кода заключается в создании таких общих правил, то отказ от объединений вам не поможет.

Что касается Google App Engine, он поддерживает отношения между сущностями, но, поскольку это не строго модель реляционной базы данных, концепция соединения на самом деле не возникает. Вместо этого вы можете получить связанные сущности из данной ссылки, что больше похоже на интерфейс ORM для модели, это не то же самое, что соединение в SQL.

Вы можете прочитать больше здесь: http://code.google.com/appengine/articles/modeling.html

(эта ссылка была в другом ответе на эту тему, но была удалена)

Я думаю, что Google лишает вас какого-то тяжелого вычислительного механизма, поэтому вы будете искать способы, которые будут использовать больше других видов ресурсов, например жесткие диски, поддерживающие справочные таблицы и / или таблицы подсчета, вместо того, чтобы тратить циклы ЦП на соединения и агрегирование расчет.

И это не невозможно, вам просто нужно обойти это, используя ресурсы типа Другие, чтобы помочь вам.

Точка выбора: Google не запрещает JOIN в своей базе данных, чтобы пользователи не запускали «дорогостоящие» запросы; база данных не является реляционной, поэтому команда SQL «JOIN» вообще-то не применима.

В этом смысле BigTable - это то же самое, что и SimpleDB от Amazon - данные денормализованы и лишены схем, так что вы фактически получаете огромные, эффективные хеш-таблицы с произвольными данными, разрешенными в сегментах.

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

Обычно, когда вы говорите о базах данных, не разрешающих соединения, вы говорите об очень больших базах данных, которые не обязательно помещаются на одном сервере. Недавними примерами являются облачные базы данных, такие как SimpleDB от Amazon, Службы данных Microsoft SQL и Хранилище данных Google App Engine. Некоторые предлагают ограниченные возможности соединения, но большая трудность заключается в объединении через "перегородки". В таких больших базах данных вы разделяете свои данные, чтобы они не располагались на одном сервере. Вы должны решить, как правильно его разделить.

В вашем примере я бы сохранил список ключей организации в поле в таблице контактов и наоборот. Дизайн этих баз данных отличается от вашей типичной нормализованной базы данных. Таблицы обычно представляют собой «разреженные таблицы», что в основном означает, что каждая запись может иметь любое количество полей, которые в основном представляют собой пары имя / значение. Подумайте о таблице продуктов на Amazon и о том, сколько разных полей может быть для разных типов продуктов. У книг есть количество страниц, но у MP3 есть продолжительность. В разреженной таблице эти записи будут храниться в той же таблице.

Вы можете выполнять объединения в своем приложении вместо сервера БД, извлекая результаты из каждой таблицы отдельно, а затем объединяя их, но для большинства объединений это только замедлит вас из-за задержки выполнения нескольких циклических обращений к базе данных, а не просто один.

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

Упомянутые вами базы данных в лучшем случае представляют собой хранилища записей с управлением версиями, предназначенные для хранения очень больших объемов данных на нескольких серверах. Назвать их «базой данных» было бы большой натяжкой. Они не поддерживают ни объединения, ни транзакции ACID, откаты и т. д. Вы можете писать приложения без них, но часто придется выполнять больше работы для обеспечения функциональности.

Для:

contacts --< contacts_organizations >-- organizations

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

Лучшим решением было бы хранить данные в трех таблицах и выполнять «соединения» самостоятельно.