Ось урок, згенерований за твоїм запитом, у стилі CS50: енергійний, з життєвими прикладами та фокусом на розумінні суті.

🏛 CS50: Databases, Tables, Rows, and Columns

(Або: Чому Excel — це не межа мрій, і як ми наводимо порядок у хаосі)

1. 🔥 Вступ: проблема та мотивація

Привіт, друзі! Це CS50, і сьогодні ми поговоримо про те, без чого не існує жоден Instagram, Uber, банкінг чи навіть список контактів у вашому телефоні.

Уявіть ситуацію. Ви вирішили відкрити власну піцерію. Спочатку у вас один клієнт — ваш друг. Ви записуєте його замовлення на стікері: "Олег: Пепероні, +38050...". Все супер.

Але раптом ваша піца стає вірусною в TikTok. Тепер у вас 10 000 замовлень на день. Стікери закінчилися, ви перейшли в Google Doc або текстовий файл. І тут починається пекло: * Хтось написав дату як "12 травня", хтось як "12.05", а хтось "сьогодні". * Ви хочете знайти всіх клієнтів, хто замовив "Маргариту", але Ctrl+F знаходить і тих, кого звуть Маргарита. * Файл важить гігабайт і відкривається 10 хвилин.

Риторичне питання: Як знайти замовлення Олега серед мільйона рядків тексту за мілісекунду, поки його піца не охолола?

Текстові файли тут безсилі. Нам потрібна структура. Нам потрібна База Даних.

2. 🧠 Теоретична база (без сухої академічності)

Давайте розберемо це на аналогії, яку знають усі — Excel (Google Sheets). Але уявіть собі Excel на стероїдах, який працює супершвидко і суворо дотримується правил.

🗄️ 1. Database (База Даних)

Це як ціла шафа з документами або один великий файл Excel (Workbook). * Суть: Це контейнер, де зберігаються всі ваші дані по проєкту. * Приклад: У Facebook є одна величезна база (або багато пов'язаних), де лежить усе: юзери, пости, лайки.

📋 2. Table (Таблиця)

Це як окрема папка в шафі або окремий лист (Sheet) в Excel. * Суть: Таблиця зберігає дані тільки одного типу. * Правило: У таблиці Users (Користувачі) ми не зберігаємо інформацію про Pizzas (Піци). Для піц буде окрема таблиця. Це називається поділ відповідальності.

🔢 3. Column (Стовпець / Поле)

Це заголовок у вашій таблиці. Він визначає атрибут даних. * Суть: Це питання, на яке ми відповідаємо. Наприклад: "Яке ім'я?", "Який вік?", "Яка ціна?". * Критично важливо: Кожен стовпець має суворий тип даних. Якщо стовпець називається Price (Ціна), база даних фізично не дозволить вам написати туди слово "Дорого". Тільки цифри. Це гарантує порядок.

📝 4. Row (Рядок / Запис)

Це конкретний об'єкт у таблиці. * Суть: Якщо стовпці — це питання, то рядок — це повний набір відповідей для однієї сутності (одного клієнта, однієї піци). * Інтуїтивно: Один рядок = Один юзер (або одне замовлення).

3. 🧪 Приклади (від простого до реального)

Давайте спроєктуємо базу даних для Spotify.

Етап 1: Мінімальний приклад

Нам потрібна таблиця для пісень. Назвемо її Songs.

Чого ми очікуємо? Назви пісні та виконавця.

Проблема: Що, якщо у нас дві пісні з назвою "Hello"? Як комп'ютер зрозуміє, яку видалити? Рішення: Нам потрібен унікальний ідентифікатор — ID.

Етап 2: Реальний проєкт

Додамо ID, тривалість (у секундах) і рік випуску. Це вже схоже на справжню структуру.

Таблиця: Songs

Дивіться: 1. Columns (Стовпці): Визначають структуру. release_year очікує лише число. 2. Rows (Рядки): Це самі пісні. Queen — це рядок №1. 3. ID: Це наш "паспортний номер" для кожного рядка. Навіть якщо Адель запише ще одну пісню "Hello", у неї буде інший ID (наприклад, 4).

Етап 3: Трохи складніше (Погляд у майбутнє)

А що, якщо ми хочемо додати жанр? Ви скажете: "Просто додай стовпець Genre!".

Так, але якщо ми напишемо "Rock", "rock", "Rock n Roll" — для комп'ютера це три різні жанри. Тому досвідчені розробники згодом виносять жанри в окрему таблицю Genres і посилаються на них через цифри. Але про це (про Relations) — на наступних уроках. Поки що просто запам'ятайте: ми прагнемо унікальності і точності.

4. 🛠 Практична частина

Час забруднити руки! Уявіть, що ви — архітектор бази даних.

Завдання 1: Створіть структуру Ви робите додаток для бібліотеки. Спроєктуйте таблицю Books. Які 4-5 стовпців (колонок) там обов'язково мають бути? Вкажіть тип даних для кожного (текст, число, дата).

Завдання 2: Знайдіть помилку У вас є таблиця Users зі стовпцем Age (вік, тип даних: Integer). Спробуйте вставити туди дані: * Рядок А: 25 * Рядок Б: Двадцять * Рядок В: 25.5 Що станеться з рядками Б і В? Чому?

Завдання 3: Міні-кейс (Uber) Потрібно створити таблицю Rides (Поїздки). Вимоги: Треба знати, хто їхав, звідки, куди і скільки це коштувало. Підказка: Не пишіть імена пасажирів текстом. Що краще використати, якщо у нас вже є таблиця Users з їхніми ID?

Завдання 4: А що, якщо... Ви робите таблицю Students. У студента може бути два номери телефону. Погана ідея: Записати в одну комірку "050-111-22-33, 097-555-44-22". Питання: Чому це погано для пошуку? Як би ви вирішили це, використовуючи лише знання про стовпці (або створивши нові рядки)?

5. 💡 Мислення як у розробника

Як відрізнити новачка від профі?

1. Типи даних — це святе.

   • Новачок: Зберігає ціну як текст "$10.99".
   • Профі: Зберігає як число 10.99 (або 1099 копійок), а знак долара додає вже в інтерфейсі програми. Тому що множити текст на податок неможливо!

2. ID (Primary Key).

   • Новачок: Шукає користувача за прізвищем.
   • Профі: Знає, що прізвища змінюються, можуть повторюватися і писатися з помилками. ID — це назавжди. Завжди додавайте стовпець id першим.

3. Атомарність (Розділяй і володарюй).

   • Не пишіть повну адресу в одну клітинку ("Київ, вул. Хрещатик, 1").
   • Краще розбийте: City, Street, House_Number. Тоді ви зможете легко запитати базу: "Покажи всіх клієнтів з Києва".

6. 🧩 Підсумок

Отже, що ми сьогодні вивчили? Ми перейшли від хаосу папірців до стрункої системи. * Database — це наш склад. * Table — це конкретний стелаж (Користувачі, Товари). * Column — це етикетка на полиці, яка каже, що і якого типу тут лежить. * Row — це сам предмет на полиці (конкретний юзер чи товар).

Що ви тепер вмієте? Ви можете взяти будь-який об'єкт реального світу (квиток у кіно, кросівок, повідомлення в чаті) і розкласти його на табличну структуру. Це і є основа програмування.

Спойлер наступного уроку: Уявіть, що у вас є таблиця Users і таблиця Orders. Як зробити так, щоб ми знали, який саме юзер зробив замовлення, не копіюючи його ім'я в кожне замовлення? Ми поговоримо про магію зв'язків — Relations та Foreign Keys.

А поки що — це був CS50. Побачимось!