Как вы не делаете присоединения? - PullRequest
3 голосов
/ 04 января 2009

В последнее время я много читал о том, как объединения в запросах БД замедляют работу. Очевидно, Google App Engine даже не позволяет им.

Мне интересно, как люди разрабатывают приложение без каких-либо объединений. Например, я работаю над приложением, которое имеет contacts и organizations. Контакт может быть во многих организациях, и организация может иметь много контактов. Как было бы возможно иметь эти отношения без третьей таблицы, которая связывает две сущности ...

contacts --< contacts_organizations >-- organizations

Означает ли это, что в GAE вы не можете иметь отношения многих ко многим? Вы просто пропускаете функциональность, которая потребует объединения?

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

Ответы [ 7 ]

13 голосов
/ 05 января 2009

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

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

Вышеприведенные высказывания предназначены для иронии.

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

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


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

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

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

7 голосов
/ 05 января 2009

Точка выбора: Google не запрещает JOINs в своей базе данных, чтобы пользователи не могли выполнять «дорогие» запросы; база данных не реляционная, поэтому глагол SQL «ПРИСОЕДИНИТЬСЯ» в действительности не применим.

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

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

3 голосов
/ 05 января 2009

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

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

3 голосов
/ 04 января 2009

Вы используете db.ReferenceProperty для связывания объектов, см. Google App Engine: JOIN один-ко-многим для подробностей и примеров.

1 голос
/ 05 января 2009

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

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

1 голос
/ 05 января 2009

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

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

0 голосов
/ 24 июля 2009

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

Для:

contacts --< contacts_organizations >-- organizations

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...