Bazy Danych i Tabele

Witaj z powrotem.

W poprzedniej lekcji zainstalowałeś PostgreSQL, otworzyłeś psql, stworzyłeś pierwszą bazę danych, pierwszą tabelę, wstawiłeś dane i uruchomiłeś pierwsze SELECT.

To już jest prawdziwa praca z bazą danych.

Mała.

Ale prawdziwa.

Dzisiaj zwolnimy i popatrzymy na coś bardzo ważnego:

Bazy danych i tabele.

Tak.

Nazwy brzmią prosto.

Ale właśnie tutaj rodzi się wiele przyszłych problemów.

Zła struktura tabeli jest jak bałagan w garażu.

Na początku wszystko wygląda normalnie.

Potem pewnego dnia potrzebujesz jednego kabla.

I nagle walczysz ze starym rowerem, trzema pudełkami i tajemniczym krzesłem, którego nikt nie pamięta.

W PostgreSQL struktura ma znaczenie.

Bardzo duże.

Czego Się Nauczysz

W tej lekcji nauczysz się:

• czym jest baza danych;
• czym jest tabela;
• jak działają wiersze i kolumny;
• czym są rekordy;
• jak myśleć o projektowaniu tabel;
• jak wybierać dobre nazwy tabel;
• jak wybierać dobre nazwy kolumn;
• jak tworzyć wiele tabel;
• jak sprawdzać strukturę tabeli;
• jak bezpiecznie usuwać tabele;
• jak unikać typowych błędów projektowych.

Na końcu tej lekcji będziesz rozumieć, jak PostgreSQL organizuje dane.

Nie tylko jak wpisywać komendy.

Zaczniesz myśleć jak developer baz danych.

Lekko niebezpieczne.

Bardzo użyteczne.

Baza Danych vs Tabela

Baza danych to kontener.

Tabela to miejsce, gdzie żyją prawdziwe uporządkowane dane.

Przykład:

Database: learning_postgresql

Tables:
  students
  books
  courses

Baza danych zawiera tabele.

Tabele zawierają wiersze.

Wiersze zawierają prawdziwe dane.

Możesz myśleć o tym tak:

Baza danych = dom
Tabela       = pokój
Wiersz       = rzecz w pokoju
Kolumna      = szczegół o tej rzeczy

Na przykład w tabeli students:

id | name   | age | email
---|--------|-----|-------------------
1  | Anna   | 22  | anna@example.com
2  | Marco  | 28  | marco@example.com

Tabela to students.

Każdy wiersz to jeden student.

Każda kolumna opisuje coś o studencie.

Prosta idea.

Bardzo potężna.

I bardzo łatwa do zepsucia, jeśli nie uważasz.

Jak kable za biurkiem.

Wiersze i Kolumny

Tabela ma kolumny i wiersze.

Kolumny definiują strukturę.

Wiersze zawierają dane.

Przykład:

tabela products

id | name     | price | available
---|----------|-------|----------
1  | Laptop   | 900   | true
2  | Mouse    | 25    | true
3  | Keyboard | 70    | false

Kolumny:

• id;
• name;
• price;
• available.

Wiersze:

• wiersz Laptop;
• wiersz Mouse;
• wiersz Keyboard.

Kolumna mówi, jaki typ informacji można zapisać.

Wiersz zapisuje jedną prawdziwą rzecz.

To jest ważne.

Nie twórz nowej kolumny dla każdego nowego elementu.

Zły pomysł:

student1 | student2 | student3
---------|----------|---------
Anna     | Marco    | Viktor

Lepszy pomysł:

id | name
---|--------
1  | Anna
2  | Marco
3  | Viktor

Wiersze są dla rekordów.

Kolumny są dla właściwości.

Ta zasada ratuje życie.

Życie baz danych.

Ale nadal ważne.

Czym Jest Rekord?

Rekord to jeden wiersz w tabeli.

W tej tabeli:

students

id | name   | age
---|--------|----
1  | Anna   | 22
2  | Marco  | 28

Anna jest jednym rekordem.

Marco jest drugim rekordem.

Rekord zwykle reprezentuje jedną rzecz:

• jednego użytkownika;
• jeden produkt;
• jedno zamówienie;
• jedną książkę;
• jeden kurs;
• jedno zadanie.

Jeśli tabela nazywa się books, jeden wiersz powinien być jedną książką.

Jeśli tabela nazywa się users, jeden wiersz powinien być jednym użytkownikiem.

Jeśli tabela nazywa się orders, jeden wiersz powinien być jednym zamówieniem.

Brzmi oczywiście.

Ale chaos w bazach danych często zaczyna się wtedy, kiedy jeden wiersz próbuje reprezentować za dużo rzeczy.

Jeden wiersz nie powinien próbować być użytkownikiem, zamówieniem, płatnością i paragonem za pizzę.

Nawet PostgreSQL ma granice.

Emocjonalnie.

Połącz Się z Bazą Danych

Otwórz PostgreSQL:

sudo -iu postgres psql

Połącz się z bazą danych z lekcji 1:

\c learning_postgresql

Jeśli jej nie masz, utwórz ją:

CREATE DATABASE learning_postgresql;

Potem połącz się:

\c learning_postgresql

Teraz jesteś gotowy.

Drzwi bazy danych są otwarte.

Proszę, nie wbiegaj w meble.

Wyświetl Tabele

Aby wyświetlić tabele w aktualnej bazie danych, uruchom:

\dt

Możesz zobaczyć:

students

Jeśli stworzyłeś tabelę w lekcji 1.

Jeśli nie widzisz żadnych tabel, wszystko dobrze.

Pusta baza danych.

Świeży start.

Jak nowy notes.

Pięknie.

Lekko stresująco.

Stwórz Tabelę Books

Stwórzmy nową tabelę o nazwie books.

CREATE TABLE books (
  id SERIAL PRIMARY KEY,
  title VARCHAR(150) NOT NULL,
  author VARCHAR(100),
  year_published INTEGER
);

Ta tabela ma:

• id;
• title;
• author;
• year_published.

Teraz wyświetl tabele:

\dt

Powinieneś zobaczyć:

books
students

Teraz mamy więcej niż jedną tabelę.

Baza danych zaczyna być małą biblioteką.

Bardzo profesjonalnie.

Prawie.

Sprawdź Strukturę Tabeli

Aby sprawdzić strukturę tabeli books, uruchom:

\d books

PostgreSQL pokaże strukturę tabeli.

Zobaczysz nazwy kolumn, typy danych i ograniczenia.

Coś takiego:

id             | integer
title          | character varying(150)
author         | character varying(100)
year_published | integer

To jest użyteczne, kiedy zapomnisz, jakie kolumny stworzyłeś.

A zapomnisz.

Bez wstydu.

Bazy danych pamiętają, bo ludzie nie pamiętają.

Taki mamy układ.

Wstaw Książki

Teraz wstaw kilka książek:

INSERT INTO books (title, author, year_published)
VALUES ('Clean Code', 'Robert C. Martin', 2008);

INSERT INTO books (title, author, year_published)
VALUES ('The Pragmatic Programmer', 'Andrew Hunt', 1999);

INSERT INTO books (title, author, year_published)
VALUES ('Database Design for Mere Mortals', 'Michael J. Hernandez', 2013);

Teraz odczytaj dane:

SELECT * FROM books;

Powinieneś zobaczyć swoje książki.

Tabela nie jest już pusta.

Ma dane.

Tabela bez wierszy to tylko plan.

Tabela z wierszami to miejsce, gdzie zaczyna się historia.

Bardzo poetycko.

Jak na SQL.

Nazwy Tabel

Dobre nazwy mają znaczenie.

Nazwa tabeli powinna opisywać, co tabela przechowuje.

Dobre nazwy tabel:

students
books
products
orders
customers
courses

Złe nazwy tabel:

data
stuff
things
my_table
table1
new_table_final_final_real

Nie nazywaj tabel tak, jak awaryjne pliki na pulpicie.

PostgreSQL zasługuje na więcej.

Ty też.

Używaj jasnych nazw.

W tym kursie zwykle będziemy używać nazw tabel w liczbie mnogiej:

students
books
orders
products

Dlaczego liczba mnoga?

Bo tabela przechowuje wiele rekordów.

Tabela students przechowuje wielu studentów.

Prosto.

Czytelnie.

Nie wszyscy zgadzają się w sprawie liczby mnogiej i pojedynczej.

To normalne.

Najważniejsza jest spójność.

Wybierz jeden styl.

Używaj go wszędzie.

Nie twórz student, books, order_table i tbl_products w jednej bazie danych.

To nie jest design.

To zupa.

Nazwy Kolumn

Nazwy kolumn też powinny być jasne.

Dobre nazwy kolumn:

id
title
author
email
created_at
year_published
price
is_active

Złe nazwy kolumn:

x
value
data1
thing
info
abc

Nazwa kolumny powinna odpowiadać na pytanie:

Co jest tutaj zapisane?

Przykład:

CREATE TABLE courses (
  id SERIAL PRIMARY KEY,
  title VARCHAR(150) NOT NULL,
  description TEXT,
  price INTEGER
);

To jest czytelne.

Możesz zrozumieć, co tabela przechowuje.

Twój przyszły ty to doceni.

Twój przyszły ty już jest zmęczony.

Pomóż mu.

Używaj snake_case

W PostgreSQL często używa się snake_case.

Dobrze:

year_published
created_at
first_name
last_name
is_active

Unikaj spacji:

year published
first name

Unikaj mixed case:

yearPublished
FirstName

PostgreSQL potrafi obsłużyć nazwy mixed-case w cudzysłowach, ale szybko robi się to irytujące.

Irytujący przykład:

SELECT "FirstName" FROM users;

Nie, dziękuję.

Używaj małych liter i snake_case.

Baza będzie czystsza.

Zapytania będą łatwiejsze.

Przyszłe debugowanie będzie miało mniej łez.

Jedna Tabela, Jeden Temat

Tabela zwykle powinna przechowywać jeden typ rzeczy.

Dobrze:

students
courses
teachers

Źle:

students_and_courses_and_teachers

Dlaczego?

Bo różne rzeczy mają różne dane.

Student ma:

• imię;
• email;
• wiek.

Kurs ma:

• tytuł;
• opis;
• cenę.

Nauczyciel ma:

• imię;
• przedmiot;
• email.

Nie mieszaj wszystkiego w jednej wielkiej tabeli.

Wielka tabela na początku wygląda łatwo.

Potem staje się potworem.

I nie uroczym potworem.

Potworem arkusza kalkulacyjnego.

Straszne.

Stwórz Tabelę Courses

Teraz stwórz kolejną tabelę:

CREATE TABLE courses (
  id SERIAL PRIMARY KEY,
  title VARCHAR(150) NOT NULL,
  description TEXT,
  price INTEGER
);

Wstaw kilka kursów:

INSERT INTO courses (title, description, price)
VALUES ('PostgreSQL Basics', 'Learn database fundamentals with PostgreSQL.', 49);

INSERT INTO courses (title, description, price)
VALUES ('JavaScript Basics', 'Learn JavaScript from the beginning.', 59);

INSERT INTO courses (title, description, price)
VALUES ('HTML and CSS', 'Build clean web pages with HTML and CSS.', 39);

Odczytaj dane:

SELECT * FROM courses;

Teraz twoja baza danych ma przynajmniej trzy możliwe tabele:

students
books
courses

Każda tabela ma swój temat.

Dobrze.

Czysto.

Baza danych zatwierdza.

Prawdopodobnie.

Typy Danych Mają Znaczenie

Każda kolumna ma typ danych.

Przykład:

title VARCHAR(150)
price INTEGER
description TEXT

Typ danych mówi PostgreSQL, jaki typ wartości może trafić do kolumny.

Na przykład:

price INTEGER

oznacza, że cena powinna być liczbą.

To dobrze.

Bo bazy danych powinny chronić strukturę.

Jeśli pozwolisz każdej kolumnie przyjmować wszystko, chaos przyjdzie w okularach przeciwsłonecznych.

Typy danych poznamy dokładniej później.

Na razie zapamiętaj:

Używaj kolumn tekstowych dla tekstu.

Używaj kolumn liczbowych dla liczb.

Używaj kolumn boolean dla true lub false.

Używaj dat dla dat.

Nie zapisuj wszystkiego jako tekst.

To bazodanowa wersja wrzucenia wszystkich narzędzi do jednego pudełka i nazwania tego organizacją.

NULL i NOT NULL

Kolumna może pozwalać na puste wartości.

W SQL pusta lub brakująca wartość nazywa się NULL.

Przykład:

CREATE TABLE teachers (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  email VARCHAR(150),
  subject VARCHAR(100)
);

Tutaj:

name VARCHAR(100) NOT NULL

oznacza, że imię jest wymagane.

Ale:

email VARCHAR(150)

może być puste.

Więc to zadziała:

INSERT INTO teachers (name, subject)
VALUES ('Laura', 'Databases');

Bo email nie jest wymagany.

Ale to nie zadziała:

INSERT INTO teachers (email, subject)
VALUES ('laura@example.com', 'Databases');

Dlaczego?

Bo name jest wymagane.

PostgreSQL pilnuje zasady.

Bardzo surowo.

Bardzo użytecznie.

Jak pies stróżujący ze znajomością SQL.

Stwórz Tabelę Teachers

Stwórz tabelę:

CREATE TABLE teachers (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  email VARCHAR(150),
  subject VARCHAR(100)
);

Wstaw dane:

INSERT INTO teachers (name, email, subject)
VALUES ('Laura', 'laura@example.com', 'Databases');

INSERT INTO teachers (name, subject)
VALUES ('Paolo', 'Web Development');

Teraz odczytaj:

SELECT * FROM teachers;

Powinieneś zobaczyć, że Paolo nie ma emaila.

Ta brakująca wartość to NULL.

Jest dozwolona, bo kolumna email nie ma NOT NULL.

To jest projektowanie tabel.

Ty decydujesz, co jest wymagane.

PostgreSQL to egzekwuje.

Ty jesteś architektem.

PostgreSQL jest poważnym budowniczym.

Usuń Tabelę

Czasami trzeba usunąć tabelę.

Uważaj.

To usuwa tabelę i jej dane.

Przykład:

DROP TABLE teachers;

PostgreSQL usunie tabelę.

Na zawsze.

Bez emocjonalnego powrotu.

Dla bezpieczeństwa możesz użyć:

DROP TABLE IF EXISTS teachers;

To znaczy:

Usuń tabelę, jeśli istnieje.
Jeśli nie istnieje, nie pokazuj błędu.

Nie usuwaj tabel losowo.

To nie jest gra.

No dobrze, to kurs.

Ale nadal.

Szanuj DROP.

Ma moc.

Za dużo mocy jak na słowo z czterech liter.

Stwórz Tabelę Ponownie

Jeśli usunąłeś teachers, możesz ją stworzyć ponownie:

CREATE TABLE teachers (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  email VARCHAR(150),
  subject VARCHAR(100)
);

To jest użyteczne do ćwiczeń.

Podczas nauki można tworzyć i usuwać testowe tabele.

Tylko nie rób tego na produkcji.

Produkcyjne bazy danych nie są placem zabaw.

Są bardziej jak muzea z prądem.

Dotykaj ostrożnie.

Typowe Błędy Projektowe

Jedna Wielka Tabela

Zły pomysł:

users_orders_products_payments

Jedna tabela do wszystkiego.

Robi się trudna do czytania, aktualizacji i zrozumienia.

Lepiej:

users
orders
products
payments

Osobne tabele dla osobnych rzeczy.

Czysta struktura.

Mniej płaczu.

Złe Nazwy Kolumn

Źle:

n
em
val
thing1
thing2

Lepiej:

name
email
price
created_at

Jasne nazwy ułatwiają SQL.

Niejasne nazwy denerwują twojego przyszłego siebie.

A twój przyszły ty wie, gdzie mieszkasz.

Zapisywanie List w Jednej Kolumnie

Źle:

student_name | courses
-------------|-------------------------------
Anna         | PostgreSQL, JavaScript, HTML

To wygląda łatwo.

Ale później trudno to wyszukiwać, aktualizować i łączyć z innymi danymi.

Lepszy design używa osobnych tabel.

Relacje poznamy później.

Na razie zapamiętaj:

Jeśli wartość zawiera listę, może potrzebuje osobnej tabeli.

Bazy danych szepczą takie rzeczy.

Słuchaj uważnie.

Praktyka

Stwórz tabelę o nazwie movies.

Powinna mieć:

• id;
• title;
• director;
• year_released;
• rating.

Przykład:

CREATE TABLE movies (
  id SERIAL PRIMARY KEY,
  title VARCHAR(150) NOT NULL,
  director VARCHAR(100),
  year_released INTEGER,
  rating INTEGER
);

Wstaw trzy filmy:

INSERT INTO movies (title, director, year_released, rating)
VALUES ('Inception', 'Christopher Nolan', 2010, 9);

Odczytaj wszystkie filmy:

SELECT * FROM movies;

Potem sprawdź strukturę tabeli:

\d movies

Potem wyświetl wszystkie tabele:

\dt

To pomoże ci przećwiczyć:

• tworzenie tabeli;
• wybieranie kolumn;
• wstawianie wierszy;
• czytanie wierszy;
• sprawdzanie struktury.

Bardzo praktyczne.

Bardzo SQL.

Mini Wyzwanie

Stwórz małą strukturę bazy danych dla platformy edukacyjnej.

Potrzebujesz trzech tabel:

students
courses
teachers

Każda tabela powinna mieć przynajmniej trzy kolumny.

Przykład:

students:
  id
  name
  email

courses:
  id
  title
  price

teachers:
  id
  name
  subject

Stwórz tabele.

Wstaw przynajmniej dwa wiersze do każdej tabeli.

Potem uruchom:

SELECT * FROM students;
SELECT * FROM courses;
SELECT * FROM teachers;

To nadal proste.

Ale teraz myślisz strukturą bazy danych.

Nie tylko komendami.

I o to chodzi.

Podsumowanie

Dzisiaj nauczyłeś się:

• baza danych zawiera tabele;
• tabele zawierają wiersze i kolumny;
• wiersz jest też nazywany rekordem;
• każda tabela powinna przechowywać jeden typ rzeczy;
• dobre nazwy tabel są jasne i spójne;
• dobre nazwy kolumn opisują dane;
• snake_case to dobry styl nazw;
• typy danych określają, jaką wartość przechowuje kolumna;
• NULL oznacza brakującą wartość;
• NOT NULL sprawia, że kolumna jest wymagana;
• \dt pokazuje tabele;
• \d table_name pokazuje strukturę tabeli;
• DROP TABLE usuwa tabelę i jej dane;
• dobra struktura chroni przed przyszłym chaosem.

Ta lekcja może wyglądać prosto.

Ale jest ekstremalnie ważna.

Zły design bazy danych tworzy problemy, które powoli dostają zęby.

Dobry design sprawia, że przyszłe zapytania są łatwiejsze, bezpieczniejsze i czystsze.

PostgreSQL jest potężny.

Ale nie uratuje cię przed tabelą o nazwie stuff.

Bądź dobry dla swojej bazy danych.

Nazywaj rzeczy poprawnie.

Strukturuj rzeczy jasno.

Twój przyszły ty nie będzie wysyłał ci złych wiadomości.

Może.

Następna Lekcja

W następnej lekcji nauczymy się podstawowych komend SQL:

• SELECT;
• INSERT;
• UPDATE;
• DELETE.

To są główne akcje pracy z danymi.

Czytaj.

Twórz.

Zmieniaj.

Usuwaj.

Krąg życia bazy danych.

Ze średnikami.