Руководство по созданию эффективных запросов

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

---

Глава 
9
Проектирование 
имеет значение
Во введении мы отметили, что оптимизация начинается во время сбора 
требований и проектирования. Если быть точным, все начинается с про-
ектирования системы, включая проектирование схемы базы данных, но не-
возможно правильно спроектировать базу данных, если не потратить время 
на сбор информации об объектах, которые должны в ней храниться. В этой 
главе мы обсудим различные возможные решения и покажем, как они могут 
повлиять на производительность.
П
роектирование
 
имеет
 
значение
В главе 1 описаны два различных решения для хранения информации о теле-
фонных номерах, показанные на рис. 1.1 и 1.2. Вернемся к этому примеру.
В лис тинге 9.1 показаны определения таблиц, используемые в схеме 
postgres_air
. Таблица 
account
содержит информацию об учетных записях 
пользователей, а таблица 
phone
содержит информацию обо всех телефонах, 
связанных с учетными записями. Эта связь поддерживается ограничением 
внешнего ключа.
В лис тинге 9.2 показан альтернативный вариант, в котором все телефоны 
хранятся вместе с информацией об учетной записи.
Есть несколько причин, по которым для схемы 
postgres_air
был выбран ва-
риант с двумя таблицами; как уже говорилось в главе 1, у многих нет домашних 
стационарных телефонов или отдельного рабочего телефона, а у кого-то есть 
несколько сотовых телефонов или виртуальный номер, такой как Google Voice. 
Все эти сценарии могут поддерживаться решением с двумя таблицами, но они 
не вписываются в вариант с одной таблицей, если только мы не начнем для 
каждого случая добавлять новый столбец. Указание основного телефона в ре-
шении с одной таблицей потребует повторения одного из номеров в столбце 
primary_phone
, создавая возможность для несогласованности. С точки зрения 
производительности решение с двумя таблицами также более выгодно.

---