[1] add report for 1-st exersize

KislyuninED/docks/report_1-st-exersize.md

@@ -0,0 +1,55 @@
+# Отчёт по лабе: телефонный справочник на трёх структурах
+
+## Что делал
+
+Реализовал три структуры для хранения записей (имя – телефон) без классов, только словари и ссылки:
+
+1. **Связный список** – каждый узел `{'name': ..., 'phone': ..., 'next': ...}`.  
+   Вставка в начало, перед этим проверка на дубликат (поиск по всему списку).
+
+2. **Хеш-таблица** – 13 корзин, в каждой связный список. Хеш-функция: сумма кодов символов `% 13`.  
+   Вставка/поиск/удаление – через хеш + вызов функций списка для конкретной корзины.
+
+3. **Двоичное дерево поиска** – узел `{'name': ..., 'phone': ..., 'left': ..., 'right': ...}`.  
+   Вставка и поиск итеративные (циклы), удаление рекурсивное с поиском inorder‑преемника.
+
+Операции везде: `insert`, `find`, `delete`, `list_all` (для дерева – обход по порядку, для остальных – собрать всё в список и отсортировать).
+
+## Эксперимент
+
+Взял **1000 записей** вида `User_00001` … `User_01000`.  
+Подготовил два набора: случайный порядок и отсортированный по имени.
+
+Для каждой структуры и каждого набора:
+
+- Замерял время вставки всех 1000 записей (через `time.perf_counter()`).
+- Затем поиск 110 имён (100 реальных + 10 вымышленных).
+- Потом удаление 50 случайных записей.
+
+Каждый замер повторял 5 раз, брал среднее.  
+Результаты сохранил в `results.csv`, потом построил график `performance.png`.
+
+## Что получилось (график)
+
+![performance](performance.png)
+
+## Анализ
+
+**BST**  
+На случайных данных работал очень быстро (логарифм). А на отсортированных – ужасно: дерево выродилось в правую цепочку, высота стала 1000. Вставка замедлилась в ~58 раз, поиск и удаление тоже сильно просели. Это классическая проблема небалансированного дерева.
+
+**Хеш-таблица**  
+Порядок данных почти не влияет. И в случайном, и в отсортированном режимах время одинаковое. Хеш-функция разбрасывает записи по корзинам, поэтому ей всё равно, откуда приходят данные.
+
+**Связный список**  
+Ожидаемо медленный везде, потому что поиск всегда линейный (`O(n)`). Разницы между случайным и отсортированным нет – список не умеет использовать порядок.
+
+**Удаление** – похоже на поиск по скорости, плюс чуть-чуть на перестановку ссылок. У хеш-таблицы удаление быстрее всего.
+
+## Выводы
+
+- **Хеш-таблица** – лучший выбор, если нужен быстрый поиск и порядок вывода не важен. Стабильна и проста.
+- **Двоичное дерево поиска** – хороший вариант, если часто нужен отсортированный список, но **только при случайных данных**. Если данные могут прийти отсортированными, дерево сломается (станет как список). Надо брать сбалансированное (AVL, красно-чёрное).
+- **Связный список** – для реальной базы контактов не годится. Можно использовать только когда записей совсем мало (до сотни) или чисто в учебных целях.
+
+Для телефонного справочника с тысячами записей я бы взял хеш-таблицу, а если надо часто выводить по алфавиту – сбалансированное дерево.