fixed mistakes

dmedvedev/10.3.Optimization of select.sql

@@ -46,13 +46,13 @@ WHERE EXTRACT(YEAR FROM created_at) = 2026
     AND LOWER(country) = 'россия'
     AND age + 10 > 35;
 
-
+CREATE INDEX users_lower_country_idx ON users (LOWER(country));
 SELECT id, name, age
 FROM users 
 WHERE 
 	created_at >= '2026-01-01' AND created_at < '2027-01-01'
-	AND country IN ('россия', 'Россия', 'РОССИЯ')
+    AND LOWER(country) = 'россия'
 	AND age > 25;
 
-Исправлено: выдача колонок "все" заменено на "определенные", логика в where с числами переработана, соответствие определенному году переработано и убрал функцию LOWER.
+Исправлено: Добавлен индекс, который приведет все строки данного столбца в нижний регистр и дальнейший поиск будет производиться только по индексу.
 

dmedvedev/10.4.Explain.sql

@@ -12,7 +12,7 @@ WHERE id = 1;
 --  Строка означает фильтрацию столбца по индексу, который есть в столбце id.
 
 Почему база использует индекс, а не читает всю таблицу?
---В моем случае БД читает всю таблицу, но обычно если индексы расставлены верно и таблица больших размеров, то БД лучше использовать индексы для повышенной производительности.
+--Потому что по полю есть индекс и таким образом оптимизатор ускоряет чтение.
 ----------
 
 --Задача 2 — Seq Scan vs Index Scan
@@ -33,13 +33,13 @@ WHERE id = 1;
 
 --Задача 4 — До и после индекса
 Запиши Execution Time и тип сканирования.
---Seq Scan, 0.059 мс, после создания индекса запрос составил 0.026мс
+--Index Scan, 0,06 мс после создания индекса.
 
 Изменился ли тип сканирования?
--- Нет, не изменился, не могу понять почему.
+-- да, изменился.
 
 Стал ли запрос быстрее? На сколько?
---Да, в 2 раза
+--Да, в 21 раза
 
 Почему индекс помог?
 --Потому что не пришлось искать по всей таблице.

dmedvedev/10.5.Porydok.sql

@@ -278,7 +278,7 @@
             FROM users u
             LEFT JOIN orders o ON o.user_id = u.id
             WHERE u.country = 'Россия'
-            GROUP BY u.name, u.age
+            GROUP BY u.id, u.name, u.age
             ORDER BY orders_count DESC;
 
             Второй запрос через JOIN  выполняется быстрее (0.13 и 0.1 мс соответственно)

dmedvedev/2.1.theory_bd_indexes.sql

@@ -200,4 +200,4 @@
     В чём выгода индекса и где он не поможет
            
             Индекс помогает искать данные быстрее (индекс это как содержание в книге) за счет плана в виде дерева. 
-            Индекс не поможет в тех столбцах, где уникальность данных мала, а также где есть сортировка по знакам >, < или поиск по части строки = "%abc".
+            Индекс не поможет в тех столбцах, где уникальность данных мала, а также где есть сортировка по части строки, например "%abc" или если индекс не по функции .

dmedvedev/2.6.theory_bd_acid_base.sql

@@ -7,7 +7,7 @@
     **Нужно:**
     
     - указать, какие свойства ACID здесь особенно важны и почему;
-            АТОМАРНОСТЬ, ДЮРАБИЛИТИ (ОТСУТСТВУЕТ НАДЕЖНОСТЬ У ДАННОЙ ТРАНЗАКЦИИ), СОГЛАСОВАННОСТЬ - НЕЛЬЗЯ ПРОВЕСТИ ОДНУ ОПЕРАЦИЮ И ЗАСЧИТАТЬ ЕЕ ДВАЖДЫ.
+                СОГЛАСОВАННОЙ ЧЕРЕЗ УНИКАЛЬНЫЙ КЛЮЧ ОБНАРУЖИВАЕТ ПОВТОРНЫЙ ЗАПРОС, А АТОМАРНОСТЬ ГАРАНТИРУЕТ, ЧТО ЭТА НЕУДАВШАЯСЯ ПОПЫТКА НЕ ИЗМЕНИТ БАЛАНС 
     - описать, какие проблемы могут возникнуть, если этих свойств не будет (например, нет атомарности или изолированности).
                 ЕСЛИ ЭТИХ СВОЙСТВ НЕ БУДЕТ, ТО ПРОИЗОЙДУТ ОШИБКИ, ДВА ОДИНАКОВЫХ ЗАПРОСА ИЛИ НЕИСПОЛНЕНИЕ ЗАПРОСА ВООБЩЕ.   
 

dmedvedev/4.4.greenplum_external_tables.sql

@@ -21,7 +21,7 @@ Greenplum ↔ PXF ↔ Hive Metastore
 1. Где реально хранятся данные?
         ЖАННЫЕ ХРАНЯТСЯ В ХРАНИЛИЩЕ HIVE.
 2. Можно ли писать обратно в Hive?
-        ДА, КОНЕЧНО.
+        НЕТ, НЕЛЬЗЯ.
 3. Что если структура таблицы в Hive изменилась?
         В ТАКОМ СЛУЧАЕ ПРИ ЗАПРОСЕ МОГУТ БЫТЬ ОШИБКИ ИЛИ ПУСТЫЕ СТОЛБЦЫ СО ЗНАЧЕНИЯМИ, ТАК КАК GREENPLUM НИКАКИМ ОБРАЗОМ НЕ СМОЖЕТ УСЗНАТЬ КАКИЕ ИЗМЕНЕНИЯ ПРОИЗОШЛИ. ПОЭТОМУ НЕОБХОДИМО ПЕРЕСОЗДАТЬ ВНЕШНЮЮ ТАБЛИЦУ ПУТЕМ УДАЛЕНИЯ И СОЗДАНИЯ.
 
@@ -47,4 +47,6 @@ Greenplum ↔ PXF ↔ S3
 1. Данные копируются в Greenplum?
         НЕТ, ДАННЫЕ НЕ КОПИРУЮТСЯ.
 2. Что быстрее: EXTERNAL или `CREATE TABLE AS SELECT`?
-        CREATE TABLE AS SELECT БЫСТРЕЕ, НО МЕНЕЕ ЭФФЕКТИВНЕЕ В ДОЛГУЮ, ТАК КАК РАСХОДУЮТСЯ ОБЪЕМЫ ПАМЯТИ И ДОП МОЩНОСТИ.
+        ВСЕ ЗАВИСИТ ОТ ЦЕЛЕЙ. 
+        ДЛЯ РАЗОВОГО ИСПОЛЬЗОВАНИЯ МОЖНО ВЫБРАТЬ EXTERNAL, СОЗДАНИЕ ТАБЛИЦЫ БУДЕТ ПРАКТИЧЕСКИЕ МОМЕНТАЛЬНЫМ ПОТОМУ ЧТО СОЗДАЕТСЯ ПРОСТО ССЫЛКА НА ТАБЛИЦУ, А ВОТ ЧТЕНИЕ БУДЕТ НЕ ОЧЕНЬ ЭФФЕКТИВНЫМ.
+        ДЛЯ МНОГОКРАТНОГО ИСПОЛЬЗОВАНИЯ ЛУЧШЕ ВЫБРАТЬ CTAS, ХОТЬ МЫ И ДОЛГО КОПИРУЕМ (СОЗДАЕМ) ТАБЛИЦУ, ЗАТО ПОСЛЕДУЮЩИЕ ЧАСТЫЕ ОБРАЩЕНИЯ БУДУТ ПРОИСХОДИТЬ ГОРАЗДО БЫСТРЕЕ ЧЕМ ПРИ EXTERNAL. 

dmedvedev/4.5.greenplum_pet_project.sql

@@ -1,48 +1,43 @@
 --Добавление raw-таблиц в GREENPLUM
 CREATE TABLE raw.pet_users
 (
-    id INT PRIMARY KEY NOT NULL,
-    name VARCHAR(50) NOT NULL,
+    id INT,
+    name VARCHAR(50),
     age INT,
-    email VARCHAR(100) NOT NULL,
-    registration_date DATE NOT NULL
+    email VARCHAR(100),
+    registration_date DATE
 );
 
 CREATE TABLE raw.pet_courses
 (
-    id INT PRIMARY KEY NOT NULL,
-    title VARCHAR(100) NOT NULL,
-    category VARCHAR(50) NOT NULL,
-    created_at DATE NOT NULL
+    id INT,
+    title VARCHAR(100),
+    category VARCHAR(50),
+    created_at DATE
 );
 
 CREATE TABLE raw.pet_lessons
 (
-    id INT PRIMARY KEY NOT NULL,
-    course_id INT NOT NULL,
-    FOREIGN KEY (course_id) REFERENCES raw.pet_courses (id),
+    id INT,
+    course_id INT,
     title VARCHAR(50),
-    duration_min INT NOT NULL
+    duration_min INT
 );
 
 CREATE TABLE raw.pet_enrollments
 (
-    id INT PRIMARY KEY NOT NULL,
-    user_id INT NOT NULL,
-    FOREIGN KEY (user_id) REFERENCES raw.pet_users (id),
-    course_id INT NOT NULL,
-    FOREIGN KEY (course_id) REFERENCES raw.pet_courses (id),
-    enrolled_at DATE NOT NULL
+    id INT,
+    user_id INT,
+    course_id INT,
+    enrolled_at DATE
 );
 
 CREATE TABLE raw.pet_lesson_views
 (
-    id INT PRIMARY KEY NOT NULL,
-    user_id INT NOT NULL,
-    FOREIGN KEY (user_id) REFERENCES raw.pet_users (id),
-    lesson_id INT NOT NULL,
-    FOREIGN KEY(lesson_id) REFERENCES raw.pet_lessons (id),
-    viewed_at TIMESTAMPTZ NOT NULL
+    id INT,
+    user_id INT,
+    lesson_id INT,
+    viewed_at TIMESTAMPTZ
 );
 
 --Создание core-таблиц (измерений - dimension) в GREENPLUM
@@ -105,12 +100,12 @@ CREATE TABLE core.enrollments
 INSERT INTO core.dim_user
     (user_id, name, age, email, registration_date)
 SELECT DISTINCT
-    user_id::INT,
+    id::INT,
     name::TEXT,
     age::INT,
     email::TEXT,
     registration_date::DATE
-FROM raw.users;
+FROM raw.pet_users;
 
 --переброска для dim_course
 INSERT INTO core.dim_course