Typy danych atrybutów encji – dobór i optymalizacja pod wydajność

Praktyka, zadania 2025+, nowoczesne narzędzia · INF.03

Teoria – NOWOŚCI Jak dobierać i optymalizować typy?

Znajomość bogatego katalogu typów: INT, BIGINT, SMALLINT, DECIMAL, VARCHAR, TEXT, CHAR, DATE, TIME, DATETIME, TIMESTAMP, BOOLEAN, UUID, JSON, ENUM, BLOB
Dobór zależy od zakresu, precyzji, typowych operacji, przewidywanej liczności (np. SMALLINT vs BIGINT), wymogów wydajnościowych
Różnice w typach SQL vs. NoSQL, obsługa JSON/BSON, typy niestandardowe i cloudowe
Optymalizacja: oszczędzanie zasobów, przyspieszanie zapytań, ułatwienie kompresji i indeksowania
Nowe trendy: dynamiczne typy (chmura), walidacja JSON, rozważania bezpieczeństwa (dane osobowe, hashe z SALT)

Ćwiczenie 1 Dobór typów – porównanie INT vs BIGINT, VARCHAR(20) vs VARCHAR(255)

Zadanie: Utwórz dwie tabele z różnym typem dla tych samych danych (patrz kod). Wstaw do każdej po 1 000 000 rekordów (skrypt Python lub SQL), zmierz rozmiar i czas SELECT COUNT(*).

CREATE TABLE test_int (
  id INT PRIMARY KEY AUTO_INCREMENT,
  imie VARCHAR(20)
);
CREATE TABLE test_bigint (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  imie VARCHAR(255)
);
-- Test: zapisz czas wykonania INSERT oraz rozmiar tabel SHOW TABLE STATUS;
-- Refleksja: Jaka jest różnica w szybkości i zajmowanej pamięci?

Ćwiczenie 2 Projekt encji „Zamówienia” – dobór typów i porównanie platform

Zadanie: Zaprojektuj tabelę Zamówienia dla PostgreSQL, MySQL i MongoDB:

ID zamówienia: UUID
Data zamówienia: TIMESTAMP
Status: ENUM
Dane dostawy: JSON
Kwota: DECIMAL(12,2)

-- PostgreSQL
CREATE TABLE zamowienia (
  id UUID PRIMARY KEY,
  data_zamowienia TIMESTAMP,
  status VARCHAR(24) CHECK (status IN ('nowe','wyslane','anulowane')),
  dane_dostawy JSONB,
  kwota DECIMAL(12,2)
);

-- MySQL
CREATE TABLE zamowienia (
  id CHAR(36) PRIMARY KEY,
  data_zamowienia TIMESTAMP,
  status ENUM('nowe','wyslane','anulowane'),
  dane_dostawy JSON,
  kwota DECIMAL(12,2)
);

-- MongoDB (przykład dokumentu)
{
  _id: ObjectId(),
  id: UUID,
  data_zamowienia: ISODate(),
  status: "nowe",
  dane_dostawy: { ... },
  kwota: NumberDecimal("120.99")
}

Ćwiczenie 3 Optymalizacja tabeli pomiarów IoT

Zadanie: Dobierz typy do tabeli odbierającej 4 000 000 pomiarów dziennie:
ID urządzenia: INT
Czas pomiaru: TIMESTAMP(6)
Wartość pomiaru: DOUBLE
Opis zdarzenia: JSON

CREATE TABLE pomiary (
  id INT AUTO_INCREMENT PRIMARY KEY,
  urzadzenie_id INT,
  czas_pomiaru TIMESTAMP(6),
  wartosc DOUBLE,
  zdarzenie JSON
)
PARTITION BY RANGE (TO_DAYS(czas_pomiaru))
(
 PARTITION p2025_11 VALUES LESS THAN (TO_DAYS('2025-12-01')),
 PARTITION p2025_12 VALUES LESS THAN (TO_DAYS('2026-01-01'))
);
-- Rozważ: regularne PRUNE starych danych, indeks na urzadzenie_id+czas_pomiaru

Ćwiczenie 4 Migracje: zmiana typu „email” i rollback

Zadanie: Zmień VARCHAR(100) na VARCHAR(60) (tylko dłużsi użytkownicy) — napisz migrację i rollback.

-- Flyway / Liquibase (up)
ALTER TABLE users MODIFY email VARCHAR(60);

-- rollback (down)
ALTER TABLE users MODIFY email VARCHAR(100);
-- Przed migracją: sprawdź długości maili! SELECT id, email FROM users WHERE LENGTH(email)>60;

Ćwiczenie 5 Rozszerzenie hybrydowe: logi jako JSON

Zadanie: Przechowuj eventy jako pole JSON. Zbuduj indeks FULLTEXT na polu event_type.

CREATE TABLE logi (
  id SERIAL PRIMARY KEY,
  ts TIMESTAMP,
  event JSON
);
CREATE INDEX idx_event_type ON logi((event->>'event_type'));
-- Przykład wyszukiwania:
SELECT * FROM logi WHERE event->>'event_type' = 'error';

Ćwiczenie 6 Typy a bezpieczeństwo danych

Zadanie: Zdefiniuj pole hasło (PCI-DSS), pole email unikalne, data utworzenia niewidoczna dla użytkownika.

CREATE TABLE users_secure (
  id UUID PRIMARY KEY,
  email VARCHAR(120) NOT NULL UNIQUE,
  password_hash VARCHAR(72) NOT NULL, -- bcrypt hash, obsługuje długość 60-72 znaków
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- Hasło zawsze jako hash + salt po stronie aplikacji

Case studies Wpływ typów na wydajność i koszty

Case 1: Zamiana VARCHAR na CHAR w polach indeksowanych — czas batch insertu w MySQL/Cloud SQL.
Case 2: JSONB a TEXT w PostgreSQL (koszt indeksów, query performance na fulltext/selektywność).
Case 3: UUID vs BIGINT do globalnych ID (skala, kolizje, szybkość JOIN, kompatybilność z chmurą).

Quiz Sprawdź swoje typologiczne IQ!

Kiedy wybrać TIMESTAMP(6) zamiast DATE? W jakich zastosowaniach liczy się mikrosekunda?
W ilu bajtach na dysku zapisywany jest INT vs BIGINT?
Jakie są zalety ENUM dla wydajności?
Czym się różni VARCHAR(255) od TEXT?
Czy NOT NULL zawsze przyspiesza indeksowanie?
Jak zabezpieczyć hasła w users?
W jakim typie przechowasz geo-współrzędne?
Podaj przykład narzędzi do analizy typów w chmurze.

TIMESTAMP(6) dla precyzyjnych pomiarów IoT, walidacji czasów w transakcjach, synchronizacji multi-cloud
INT – 4 bajty, BIGINT – 8 bajtów
Oszczędność miejsca, szybkie porównania, walidacja na poziomie DB
VARCHAR(255) – elastyczny, TEXT – dla >255 znaków, inne limity indeksowania
Często tak (unikamy NULL w indexach B-tree), ale nie zawsze – optymalizuj przypadki edge-case
Zawsze jako hash (bcrypt, scrypt) + salt, nigdy plaintext
GEOMETRY, POINT, JSON, (array dla NoSQL)
pgstattuple, SQLFluff, narzędzia chmurowe do audytu schematów

Checklista Kompetencje po module

Dobieram precyzyjnie typy wg rozmiaru i przeznaczenia
Optymalizuję strukturę pod kątem wydajności i kosztów storage
Stosuję typy specjalne, kompozytowe i JSON
Praktykuję migracje, upgrade, rollback schematu
Korzystam z narzędzi do monitoringu i analizy typów

Nowoczesne trendy Narzędzia, inspiracje, świat 2025+

dbdiagram.io – modelowanie i wizualizacja struktur
SQLFluff, Lintery – automatyczne sprawdzanie jakość typowania
Flyway, Liquibase – zarządzanie migracjami i wersjami typów
Google Cloud SQL, AWS RDS, Azure SQL – zgodność typów danych i audyty bezpieczeństwa
Dobre praktyki: staging/mock, audyt typów przed wdrożeniem, narzędzia do testów