Temat: problem z zaprojektowaniem

Witam

Z przyjemnością wczytałem się w ten wątek. Ciekawe pomysły i uwagi.

A co do wydajności to w tym konkretnym przypadku nie domonizowałbym sprawy:

1. O prędkości wydobycia danych decydują indeksy - odpowiednie do zadawanych zapytań (pomijam tu sprawy wydajnościowe serwerów).

2. Co się tyczy rozmiaru danych:

Policzmy 500 * 10 * 10 = 50000 pozycji zamówień sprzedaży dziennie. Przyjmijmy że rekord pozycji wygląda ~ tak:

id_pozycje_zamowienia = 8b
id_zamowienia = 8b
id_towaru = 8b
ilosc = 4b
data_realizacji = 8b

// dalej ... coś w stylu potwierdzenia, itd - szczegóły które nie są nam znane ... estymuję że rekord powiększy się dwukrotnie
~ 64 bajty

co daje dzienną ilość danych ~ 2,5 Mb

chyba da się z tym żyć :)

Jeden z systemów przy którym miałem okazję pracować ... produkuje dziennie ok. 1800000 rekordów. Działa sobie to na SQL Serwerze 2005 Pro (nie twierdzę że jedynym słusznym :) ) i radzi sobie na stosunkowo niewielkich serwerach: 8GB Ramu + Quad procesor.
Baza podręczna przechowuje dane za okres ostatniego roku. Przygotowywane są dane godzinowe i miesięczne (trudno utrzymać 3 postać normalną i wydajnie odpowiadać).
--------------------------------------

Zgadzam się więc z przedmówcami twierdzącymi że kluczowa jest funkcjonalność ... życie nie zawsze jednak jest tak komfortowe!

Pozdrawiam

Temat: problem z zaprojektowaniem

Witam

Jeśli chodzi o problem z wydajnością,
to nie jest problemem liczba wierszy w tabeli,
ale jej faktyczny rozmiar, jaki zajmuje na dysku.

Także słusznie zrobiłeś szacując w bajtach wielkość takiego rekordu i co za tym idzie tabeli.
Dopiero wtedy można podejmować decyzje, co dalej zrobić z taką tabelą/bazą.

Na przykład Oracle zaleca partycjonowanie tabel dopiero, gdy przekroczą 2GB.

pzdr