Как вы можете не делать объединения?

Question

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

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

contacts --< contacts_organizations >-- organizations

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

<Ч>

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

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

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

Answer 3

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

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

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

Answer 4

Вы используете db.ReferenceProperty для связывания объектов, см. Google App Engine: СОЕДИНЕНИЕ« один ко многим » для получения подробной информации и примеров.

Answer 5

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

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

Answer 6

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

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

Answer 7

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

Для:

contacts --< contacts_organizations >-- organizations

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

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