SQL. Sztuka Programowania.pdf

(22007 KB) Pobierz
SPIS TRE
Ś
CI
Wstęp
1.
Plany strategiczne
Projektowanie baz danych pod kątem wydajności
2.
Prowadzenie wojny
Wydajne wykorzystanie baz danych
3.
Działania taktyczne
Indeksowanie
4.
Manewrowanie
Projektowanie zapytań SQL
5.
Ukształtowanie terenu
Zrozumienie implementacji fizycznej
6.
Dziewięć zmiennych
Rozpoznawanie klasycznych wzorców SQL
7.
Odmiany taktyki
Obsługa danych strategicznych
8.
Strategiczna siła wojskowa
Rozpoznawanie trudnych sytuacji i postępowanie w nich
9.
Walka na wielu frontach
Wykorzystanie współbieżności
10.
Gromadzenie sił
Obsługa dużych ilości danych
11.
Fortele
Jak uratować czasy reakcji
12.
Zatrudnianie szpiegów
Monitorowanie wydajności
Ilustracje
O autorach
Skorowidz
7
15
51
87
113
151
179
231
273
307
337
381
417
451
453
455
Bacząc na moje porady, miej również wzgląd na wszelkie pomocne
okoliczności związane z regułami, ale i niezależne od nich.
— Sun Tzu,
Sztuka wojny
WST
Ę
P
B
yły takie czasy, gdy dziedzinę zwaną dziś szumnie „technologią
informatyczną” określano „elektronicznym przetwarzaniem danych”.
I prawda jest taka,
że
przy całym szumie wokół modnych technologii
przetwarzanie danych nadal pozostało głównym zadaniem większości
systemów. Co więcej, rozmiary danych zarządzanych w sposób
elektroniczny stale się zwiększają, szybciej nawet niż wzrasta moc
procesorów. Najważniejsze dane korporacyjne są dziś przechowywane
w relacyjnych bazach danych i można uzyskać do nich dostęp za pomocą
niedoskonałego, ale za to powszechnie znanego języka SQL. Jest to
kombinacja, która zaczęła przebijać się na
światło
dzienne w połowie lat
osiemdziesiątych i do dnia dzisiejszego praktycznie zmiotła konkurencję
z powierzchni ziemi.
Trudno dziś przeprowadzić wywiad z młodym programistą, który nie
pochwaliłby się dobrą praktyczną znajomością SQL-a, powszechnie
stosowanego języka dostępu do danych. Język ten jest jedną z obowiązkowych
pozycji każdego kursu wykładów na kierunkach informatycznych. Taka
opinia na temat własnej wiedzy jest z reguły względnie uzasadniona, jeśli
przez „wiedzę” rozumiemy umiejętność uzyskiwania (po krótszych lub
dłuższych zmaganiach) funkcjonalnie poprawnych wyników. Jednakże
korporacje na całym
świecie
doświadczają sytuacji dynamicznie zwiększających
się ilości danych. W efekcie „funkcjonalnie poprawne” wyniki już nie
wystarczą: wyniki te muszą przede wszystkim być uzyskiwane
szybko.
Wydajność baz danych stała się głównym problemem w wielu firmach.
Co interesujące, choć każdy zgodzi się z faktem, iż
źródło
wydajności leży
w kodzie, akceptuje się fakt,
że
najważniejszą troską programisty powinno
8
WST
Ę
P
być pisanie działającego kodu, co wydaje się dość rozsądnym założeniem.
Z tego rozumowania wynika twierdzenie,
że
kod wykonywany przez bazę
danych powinien być jak najprostszy, przede wszystkim ze względu na
koszt utrzymania, i
że
„ciężkie przypadki” kodu SQL powinny być
rozwiązywane przez zaawansowanych administratorów baz danych, którzy
będą w stanie zoptymalizować je do szybszego działania, zapewne z użyciem
„magicznych” parametrów bazy danych. Jeśli takie działania nie wystarczą,
wszyscy zgadzają się z faktem,
że
jedynym ratunkiem jest wymiana sprzętu
na mocniejszy.
Często zdarza się,
że
tego typu podejście, oparte na zdrowym rozsądku
i postawie asekuracyjnej, w ostatecznym rozrachunku okazuje się niezwykle
szkodliwe. Pisanie niewydajnego kodu i poleganie na ekspertach, którzy
poratują w sytuacji „ciężkiego przypadku” kodu SQL, można porównać
do zamiatania brudów pod dywan. W mojej opinii to właśnie programiści
powinni interesować się wydajnością, a ich potrzebę znajomości SQL-a
oceniam nieco wyżej niż jedynie umiejętność napisania kilku zapytań.
Wydajność widziana z perspektywy programisty jest czymś zupełnie innym
od „konfigurowania” praktykowanego przez administratorów baz danych.
Administrator baz danych próbuje jak najwięcej „wycisnąć” z systemu
w oparciu o posiadany sprzęt, procesory i podsystem dyskowy oraz wersję
systemu zarządzania bazami danych. Administrator może posiadać pewne
umiejętności w używaniu SQL-a i poradzi sobie z poprawieniem wydajności
szczególnie kiepsko napisanego zapytania. Ale programiści piszą kod, który
będzie działał długo, nawet do pięciu czy dziesięciu lat i wielokrotnie
przeżyje bieżącą wersję (niezależnie od ich marketingowych haseł, jak
internet-enabled, ready-for-the-grid
czy tym podobnych) użytkowanego
systemu zarządzania bazami danych (Database Management System,
DBMS), na której był pisany, jak również kilka generacji sprzętu.
Kod musi być szybki od początku. Przykro to stwierdzić, ale z wielu
programistów, którzy „znają” SQL, niewielu rozumie zasady
funkcjonowania tego języka i ma opanowane podstawy teorii relacyjnej.
Po co kolejna książka o SQL-u?
Książki o SQL-u dzielą się na trzy podstawowe typy: książki, które uczą
logiki i składni poszczególnych dialektów SQL-a, książki, które uczą
zaawansowanych technik i opierają się na rozwiązywaniu problemów,

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin