[Ogólnie] Wielkość bazy a jej struktura

Witam jak w temacie. Sporo czytam, ale zależy mi na opinii praktyków. Pytanie jest następujące: czy tabela która w ciągu roku zyska około 1E6 rekordów powinna zostać np. podzielona na mniejsze tabele lub otrzymać np. skompresowane dane wejściowe. Jak sobie radzi z taką ilością mechanizm szukania, filtrowania, grupowania. Jeżeli możecie wypowiedzieć się z różnych perspektyw będę wdzięczny. Nie mam czasu ani energii aby kodować setki różnych wariantów tej samej bazy i przeprowadzać symulacje. ;-)

powiem tak - jak masz dużo wolnego czasu lub lubisz wycieczki krajoznawcze to możesz sobie podzielić, np. każdy miesiąc osobna tabela
btw taki sztuczny podział to same problemy, szczególnie przy wyszukiwaniu danych i robieniu raportów

Dzięki, to chciałem usłyszeć.

BTW, czyli nie zawsze warto słuchać studenta zaocznego 3 semstru informatyki :-D

A na jakim serwerze jest baza? W Oracle masz mechanizm partycjonowania tabel. Możesz sobie podzielić tabelę na mniejsze a dla SQL-a będzie to wciąż ta sama tabela. Ten mechanizm ma wiele zalet. Np możesz sobie skonfigurować partycje tabeli w ten sposób, że wszystkie starsze od aktualnej są read-only (o ile nie zmieniasz starszych rekordów oczywiście) i wtedy backup-ujesz na bieżąco tylko najnowszą. Takie rozwiązania stosuje się w "dużych" systemach.

po to ktoś wymyślił BD aby uniknąć takich problemó. Jeśli 1E6 to 1000000 rekordów to dla większości baz to jest pikuś w skali rocznej (pomijam przypadek, gdzy tym rekordem jest BLOB o rozmiaże kilka MB :)). Oczywiście próba uruchomienia tego na SQLite i Win98 oraz P500 i 128MB RAM jest skazana na porażkę :)

Musisz przede wszystkim dobierać narzedzie i sprzęt do potrzeb a nie będziesz miał takich problemów.

BTW zobacz, masz taki schemat - każdy miesiąc w osobnej tabeli, dodatkowo może być kilka lat. Jak rozwiążesz problem

1. rozpoczął się nowy miesiąc
2. zrób zestawienie z całego bierzącego roku
3. zrób zestawienie z jakiegoś roku poprzedniego
4. zrób zestawienie z kilku lat
5. znajdz (zakładając, że masz tam np. faktury) jakąś fakturę znając kontrahenta i kwotę brutto i nie znając daty (nawet roku)

oczywiście się da ale ile trzeba nakombinować.

darek963 napisał(a)

W Oracle masz mechanizm partycjonowania tabel. Możesz sobie podzielić tabelę na mniejsze a dla SQL-a będzie to wciąż ta sama tabela.

No problem with queries.

Witam !

Jeśli się nie mylę to partycjonowanie tabel w Oracle jest dostępne w wersji "enterprise", która kosztuje baaardzo dużo !

Pozdrówko

darek963 napisał(a)

darek963 napisał(a)

W Oracle masz mechanizm partycjonowania tabel. Możesz sobie podzielić tabelę na mniejsze a dla SQL-a będzie to wciąż ta sama tabela.

No problem with queries.

jeśli to odpowiedź na moje pytania to przeczytaj je jeszcze raz - pytałem o sztuczny podział nie o partycjonowanie.

jw_software napisał(a)

Witam !

Jeśli się nie mylę to partycjonowanie tabel w Oracle jest dostępne w wersji "enterprise", która kosztuje baaardzo dużo !

Pozdrówko

No cóż Mercedes S Classe też kosztuje duuużo. :) Za nowoczesne technologie niestety trzeba słono płacić.

Ok, temat się rozwija. Napiszę więcej (MisiekD, trzymaj się..., ja naprawdę nie mam wyboru...).

1). Baza - SQLite ( brak zgody na instalacje serwera SQL (myslę też nad FB embedded )
2). Komputer - Intel (jakiś mobilny w laptopie) 1.7 GHz, 1GB ram, WinXP Pro SP2
3). struktura tabeli jest taka:

CREATE TABLE daytable(
  [id]      INTEGER PRIMARY KEY NOT NULL
  [referID] INTEGER NOT NULL
  [nr]      INTEGER NOT NULL
  [builder] INTEGER NOT NULL
  [status]  CHAR(1) NOT NULL
  [area]    INTEGER DEFAULT NULL
  [code]    VARCHAR(5) DEFAULT NULL);

Interface wprowadzana jest taki (StringGrid jest odpowiednikiem raportu, więc jego modyfikacja nie wchodzi w grę, jes zaprogramowany tak, aby maksymalnie szybko wprowadzać dane):

Tabela więc dokładnie odpowiada siatce. Pomysł z kompresją polegał na tym, aby zamiast ok, ok, ok, ok, podzielić to na dwie tabele: ok, ng, potem dane wpisywać operator 7, ok*12 (pole [ok] naturalnie znika przy podziale na tabele). Ale problem będzie z odtworzeniem do np. edycji, gdyż kompresja jest stratna.

Jak widać tabela duża nie będzie. Jej rozmiar szacuję na 25MB +-5MB).
Raporty generowane będą b. proste :miesiąc, operator, maszyna, całość itp.

przy takiej strukturze powinno śmigać :) nawet przy 4x większej tabeli. Tylko indeksy pozakładaj na kluczowe pola

Dzięki za słowa otuchy, bo siedzę nad małpą już dwa miechy (przeleciałem chyba wszystkie SQLowe bazy i czasami się już poddaję. Jedno przeskoczę, w dwa następne wpadam).

To musi dzialac