Temat: Jaki był najdłuższy ciąg...

W SQL można całkiem dużo, tylko nie koniecznie zawsze ma to sens.

'Warunków brzegowych' w większości rzeczywistych przypadków mamy na tyle dużo i są one na tyle różnorodne, że nie sądzę aby można było stwierdzić że rozwiązanie czysto SQLowe/przetwarzanie batchowe/jakieś inne jest z całą pewnością lepsze dla danej klasy problemów bez dokładnego określenia całości problemu - w tym np. konkretnego zbioru danych, rodzaju generowanego/dopuszczalnego w konkretnym systemie obciążenia, oczekiwanych wyników - i samych możliwości jego realizacji (choćby know-how osób implementujących rozwiązanie, dostępności i jakości narzędzi). Chyba najczęściej łatwiej po prostu sprawdzić metodą testów, jak się dane rozwiązanie w konkretnym przypadku sprawdza, niż próbować opisać całą złożoność problemu teoretycznie.

Swoją drogą jestem ciekaw, jaką można osiągnąć wydajność dla rozwiązań batchowych - podany przez Pana limit 100 rekordów wydaje się bardzo mały (co niby baza miałaby robić z tak niewielkim zbiorem danych żeby zabrało jej to istotną ilość czasu?) i dla jakiego typu operacji jego wydajność istotnie przewyższa 'bezpośrednią' manipulację na danych z pomocą SQLa lub języków wbudowanych serwera baz danych.

Również pozdrawiam :-)Leszek Trenkner edytował(a) ten post dnia 16.01.08 o godzinie 17:05

Temat: Jaki był najdłuższy ciąg...

Leszek Trenkner:
W SQL można całkiem dużo, tylko nie koniecznie zawsze ma to sens.
(ciach)
Swoją drogą jestem ciekaw, jaką można osiągnąć wydajność dla rozwiązań batchowych - podany przez Pana limit 100 rekordów wydaje się bardzo mały (co niby baza miałaby robić z tak niewielkim zbiorem danych żeby zabrało jej to istotną ilość czasu?) i dla jakiego typu operacji jego wydajność istotnie przewyższa 'bezpośrednią' manipulację na danych z pomocą SQLa lub języków wbudowanych serwera baz danych.

Limit 100 rekordów to oczywiście limit rzucony dla przykładu. Po prostu przy 100 rekordach iloczyny kartezjańskie zaczynają już ważyć i można zauważyć wąskie gardła (np. przy tej liczbie od razu widać problemy n^3).

Co do limitów dla rozwiązań batchowych to można powiedzieć, że powinno się na nie przechodzić przy procesach przetwarzających ok. 1 mln rekordów. Oczywiście można przechodzić inkrementalnie - do osiągnięcia zadowalającego wyniku.

Parafrazując jedną z poprzednich wypowiedzi:
- jeśli można coś zrobić jednym SQL-em (i działa odpowiednio szybko) - zrób to w ten sposób
- jeśli coś można zrobić przy pomocy tabeli tymczasowej i kilku SQL-i - zrób to w ten sposób
- jeśli coś można zrobić kursorem - zrób to w ten sposób
- w innych przypadkach - batch (plik)

Wszystko zależy od tego, ile chce nam się spędzić czasu nad optymalizacją. Podaje batch jako ekstremalną formę optymalizacji. W tym przykładzie będzie to prawdopodobnie najszybsze rozwiązanie, ale jednocześnie ma to też swoje wady:
- nieodporne na zmiany rozkładu statystycznego danych
- nieodporne na zmiany struktury danych
- kosztowne w utrzymaniu