Alex tools

Индекс может быть определен более чем для одного столбца таблицы. Например, если у вас есть таблица такого вида: CREATE TABLE devtable ( major int, minor int, name varchar ); (скажем, вы храните свой каталог /dev в базе данных...) и часто выдаете такие запросы, как: SELECT name FROM devtable WHERE major = constant AND minor = constant; тогда может быть уместно определить индекс для major и minor столбцов вместе, например: CREATE INDEX devtable_mm_idx ON devtable (major, minor); В настоящее время только типы индексов B-tree, GiST, GIN и BRIN поддерживают индексы с несколькими ключевыми столбцами. Может ли быть несколько ключевых столбцов, не зависит от того, можно ли добавить столбцы INCLUDE в индекс. Индексы могут иметь до 32 столбцов, включая столбцы INCLUDE. Многостолбцовый индекс B-tree можно использовать с условиями запроса, включающими любое подмножество столбцов индекса, но индекс наиболее эффективен, когда существуют ограничения на ведущие (крайние ле

PostgreSQL предоставляет несколько типов индексов: B-tree, Hash, GiST, SP-GiST, GIN и BRIN. Каждый тип индекса использует свой алгоритм, который лучше всего подходит для разных типов запросов. По умолчанию команда CREATE INDEX создает индексы B-tree, которые подходят для наиболее распространенных ситуаций. Другие типы индексов выбираются путем написания ключевого слова USING, за которым следует имя типа индекса. Например, чтобы создать хэш-индекс: CREATE INDEX name ON table USING HASH (column); B-Tree (B-дерево) B-деревья могут обрабатывать запросы на равенство и диапазон для данных, которые можно отсортировать в некотором порядке. В частности, планировщик запросов PostgreSQL рассмотрит возможность использования индекса B-дерева всякий раз, когда индексированный столбец участвует в сравнении с использованием одного из следующих операторов: < <= = >= > Конструкции, эквивалентные комбинациям этих операторов, такие как BETWEEN и IN, также могут быть реа

Оконная функция выполняет вычисление по набору строк таблицы, которые каким-то образом связаны с текущей строкой. Это сравнимо с типом расчета, который можно выполнить с помощью агрегатной функции. Однако оконные функции не заставляют строки группироваться в одну выходную строку, как это было бы при не оконных агрегатных вызовах. Вместо этого строки сохраняют свои отдельные идентификаторы. За кулисами оконная функция может получить доступ не только к текущей строке результата запроса. Вот пример, который показывает, как сравнить зарплату каждого сотрудника со средней зарплатой в его или ее отделе: SELECT depname, empno, salary, avg(salary) OVER (PARTITION BY depname) FROM empsalary; depname | empno | salary | avg -----------+-------+--------+----------------------- develop | 11 | 5200 | 5020.0000000000000000 develop | 7 | 4200 | 5020.0000000000000000 develop | 9 | 4500 | 5020.0000000000000000 develop | 8 | 6000

Транзакции - фундаментальная концепция всех систем баз данных. Существенным моментом транзакции является то, что она объединяет несколько шагов в одну операцию по принципу "все или ничего". Промежуточные состояния между шагами не видны другим параллельным транзакциям, и если произойдет какой-либо сбой, который препятствует завершению транзакции, то ни один из шагов не повлияет на базу данных вообще. Например, рассмотрим банковскую базу данных, которая содержит остатки по различным счетам клиентов, а также общие остатки по депозитам для филиалов. Предположим, мы хотим записать платеж в размере 100 долларов США со счета Алисы на счет Боба. Предельно упрощая, команды SQL для этого могут выглядеть так: UPDATE accounts SET balance = balance - 100.00 WHERE name = 'Alice'; UPDATE branches SET balance = balance - 100.00 WHERE name = (SELECT branch_name FROM accounts WHERE name = 'Alice'); UPDATE accounts SET balance = balance + 100.00 WHERE name = 

По данным предыдущих постов . Рассмотрим следующую проблему: вы хотите убедиться, что никто не может вставлять строки в таблицу weather, для которых нет соответствующей записи в таблице cities. Это называется поддержанием ссылочной целостности ваших данных. В упрощенных системах баз данных это может быть реализовано (если вообще возможно), сначала просмотрев таблицу cities, чтобы проверить, существует ли соответствующая запись, а затем вставить или отклонить новые записи weather. Этот подход имеет ряд проблем и очень неудобен, поэтому PostgreSQL может сделать это за вас. Новое объявление таблиц будет выглядеть так: CREATE TABLE cities ( name varchar(80) primary key, location point ); CREATE TABLE weather ( city varchar(80) references cities(name), temp_lo int, temp_hi int, prcp real, date date ); Теперь попробуйте вставить недопустимую запись: INSERT INTO weather VALUES ('Berkeley', 45,

По данным предыдущих постов . Предположим, комбинированный список записей погоды и местоположения города представляет особый интерес для вашего приложения, но вы не хотите вводить запрос каждый раз, когда он вам нужен. Вы можете создать представление по запросу, которое дает имя запросу, на которое вы можете ссылаться как на обычную таблицу: CREATE VIEW myview AS SELECT name, temp_lo, temp_hi, prcp, date, location FROM weather, cities WHERE city = name; SELECT * FROM myview; Широкое использование представлений - ключевой аспект хорошего дизайна базы данных SQL. Представления позволяют вам инкапсулировать детали структуры ваших таблиц, которые могут меняться по мере развития вашего приложения, за согласованными интерфейсами. Представления можно использовать практически в любом месте, где можно использовать настоящую таблицу. Построение представлений на другие представления не редкость. Читайте также: SQL в PostgreSQL: концепции и создание таблиц SQ

До сих пор наши запросы обращались только к одной таблице за раз. Запросы могут обращаться к нескольким таблицам одновременно или к одной и той же таблице таким образом, что одновременно обрабатываются несколько строк таблицы. Запросы, которые обращаются к нескольким таблицам (или нескольким экземплярам одной и той же таблицы) одновременно, называются join запросами. Они объединяют строки из одной таблицы со строками из второй таблицы с выражением, определяющим, какие строки должны быть объединены в пары. Например, чтобы вернуть все записи weather вместе с местоположением связанного города, базе данных необходимо сравнить столбец city в каждой строке таблицы weather со столбцом name всех строк в таблице cities и выбрать пары строки, в которых совпадают эти значения. Это можно сделать с помощью следующего запроса: SELECT * FROM weather JOIN cities ON city = name; city | temp_lo | temp_hi | prcp | date | name | location ---------------+---------+------