konto usunięte

Temat: Antywzorce programisty baz danych

Witam,

temat zawarty w tytule stał się tematem mojej pracy magsiterskiej.

Chciałbym, korzystając z możliwości WEB 2.0 ;) zapytać Was, jako programistów, co takim antywzorcem może być.

Podkreślam, że temat dotyczy programistów, czyli raczej szeroko rozumianego pisania zapytań i widoków, tworzenia funkcji, i optymalizacji tychże, nie zaś projektowania bazy danyc.

Byłbym bardzo wdzięczny za każdą konstruktywną odpowiedź ;)

Tutaj np. znalazłem ciekawy przykład dla tego tematu:
http://students.mimuw.edu.pl/oracle10g/server.101/b107...

Temat: Antywzorce programisty baz danych

Pierwsze, co mi się nasuwa, to nierelacyjne bazy danych i tabele z niebotyczną ilością kolumn, których liczbę można w prosty sposób ukrócić ;-). Spotkałem się też z przypadkami, gdzie dla nowego "rekorodu" tworzyło się nową tabelę. Dowolna aplikacja podczas swojego działania nie powinna ingerować w strukturę bazy danych, która została zaprojektowana na początku (tworzenie/usuwanie tabel lub tworzenie/usuwanie kolumn w tabelach).Piotr Wittchen edytował(a) ten post dnia 18.05.08 o godzinie 14:11

konto usunięte

Temat: Antywzorce programisty baz danych

http://thedailywtf.com .. rozne perwersje komputerowe.. tez bazodanowe.. polecam przejzec archiwa.. co do samych antywzorcow to chyba ciezko jest sformulwoac cos ogolnie, i duzo prosciej jest wypunktowac wady konkretnych rozwiazan.. jest pare rzeczy oczywistach jak np.:
- tworzenie zbednych tabel dla relacji 1..N,
- nie przestrzeganie zasad normalnosci baz danych (chocby trzymanie w polu sklejki roznych danych zamiast pojedynczej wartosci),
- nieumiejetne uzywanie typow sql,
- brak spojnosci w nazewnictwie,
- nie przykladanie wagi do optymalizacji na etapie programowania.

Temat: Antywzorce programisty baz danych

To dosyć ogólne ale często programiści bazodanowi, którzy wcześniej zajmowali się programowaniem w językach imperatywnych usiłują zastosować tą konwencję w SQLu, np. poprzez nadużywanie kursorów.

konto usunięte

Temat: Antywzorce programisty baz danych

Jeden prosty przykład na antywzorzec to stosowanie indeksu klastrującego na podstawie klucza PK "technicznego" - opartego na jednym polu typu integer autoincremental.

Przypadek taki generowany może być przez narzędzia modelowania baz danych i nie ma sensu - dane nie są rozrzucane równomiernie i tworzą się hot-spoty.
Łukasz  Grzybowski-Glikm an

Łukasz
Grzybowski-Glikm
an
Konsultant CRM,
AlfaPeople;
Właściciel, Uni-Soft

Temat: Antywzorce programisty baz danych

Piotr Likus:
Jeden prosty przykład na antywzorzec to stosowanie indeksu klastrującego na podstawie klucza PK "technicznego" - opartego na jednym polu typu integer autoincremental.

Przypadek taki generowany może być przez narzędzia modelowania baz danych i nie ma sensu - dane nie są rozrzucane równomiernie i tworzą się hot-spoty.

Mógłbyś rozwinąć myśl? Zawsze wydawało mi się, że tworzenie indeksu klastrowego na PK to standard. Nie pracowałem również nigdy z bazą danych gdzie PK nie byłby syntetyczny.
Co rozumiesz pod pojęciem "hot-spoty"?
Indeks klastrowy zapewnia najwyższą wydajność, więc logiczne wydawało mi się, że zakładanie go na kolumnę po której robi się 90% "joinów" jest oczywiste. Widocznie nie do końca.

Temat: Antywzorce programisty baz danych

Łukasz Kowalski-Glikman:
Piotr Likus:
Jeden prosty przykład na antywzorzec to stosowanie indeksu klastrującego na podstawie klucza PK "technicznego" - opartego na jednym polu typu integer autoincremental.

Przypadek taki generowany może być przez narzędzia modelowania baz danych i nie ma sensu - dane nie są rozrzucane równomiernie i tworzą się hot-spoty.

Mógłbyś rozwinąć myśl? Zawsze wydawało mi się, że tworzenie indeksu klastrowego na PK to standard. Nie pracowałem również nigdy z bazą danych gdzie PK nie byłby syntetyczny.
Co rozumiesz pod pojęciem "hot-spoty"?
Indeks klastrowy zapewnia najwyższą wydajność, więc logiczne wydawało mi się, że zakładanie go na kolumnę po której robi się 90% "joinów" jest oczywiste. Widocznie nie do końca.

Problem wynika z tego, że kolejne wielkości autoinkrementacji wpadając do indeksu usilnie są ładowane w jedną stronę drzewa. Struktura indeksu nie przyjmuje więc formatu B-tree co jest zasadnicze dla wydajności wyszukiwania po kolumnie indeksu. Taki indeks mógłby działać wydajnie, jeśli byłby regularnie przebudowywany tudzieź tworzony dopiero po wypełnieniu tabeli danymi.
Grzegorz G.

Grzegorz G. ASE / Systems
Architect, Syniverse

konto usunięte

Temat: Antywzorce programisty baz danych

Łukasz Gojowy:

Problem wynika z tego, że kolejne wielkości autoinkrementacji wpadając do indeksu usilnie są ładowane w jedną stronę drzewa. Struktura indeksu nie przyjmuje więc formatu B-tree co jest zasadnicze dla wydajności wyszukiwania po kolumnie indeksu. Taki indeks mógłby działać wydajnie, jeśli byłby regularnie przebudowywany tudzieź tworzony dopiero po wypełnieniu tabeli danymi.

To jest główny powód. Drugi to ten, że klastrujemy coś co i tak zawsze wpada w jeden sektor danych - bo wartości w indeksie kolejno rosną zamiast być rozrzucane.

Następna dyskusja:

Studia podyplomowe z Baz Da...




Wyślij zaproszenie do