🚀 go-pugleaf

On Tuesday, May 3, 2016 at 12:24:48 PM UTC+2, Borneq wrote:
> Przepraszam, może pytanie banalne.
> Ale mam bazę mySQL albo mariaDB. W niej mam gromadzić transakcje z 
> bloków Bitcoina. Przy czym jeden blok ma wiele transakcji - tabela 
> transakcje. Ale jedna transakcja może mieć wiele adresów wejściowych i 
> wyjściowych. Adresy mogą się powtarzać dla wielu transakcji.
> Kłopot że to relacyjna baza danych a nie np. obiektowa.
> Trzeba zrobić chyba tak, że w tabeli transakcje trzymać tylko hasze 
> transakcji, a pozostałe dwie tabele to będą pary (hasz,adres) jako 
> klucz. (jak zrobić parę jako jeden klucz?)

Pierwsza sprawa: Poczytaj, jest opisane jak się takie klucze i indeksy
definiuje.

Po drugie, osobiście polecam zawsze zdefiniowanie klucza bigint 
jako klucza głównego w każdej tabeli, nawet jeśli istnieje 'naturalny
klucz' typu pesel, albo Twój hash.


> ale wtedy jak będzie wyglądało przeglądanie tabeli transakcje, może 
> spowolnić gdy będę dla każdej wartości wyszukiwał adresy z relacji. 
> Potrzebne indeksy (jakie?), 
Sprawdź btree lub hash i wybierz szybszy. Gdy użyjesz biginta jako
klucza, to baza może sama wygenerować indeksy.


> jak to wszystko ułożyć aby działało szybko?
> A może dla małej ilości adresów, np. 3 trzymać je w tabeli transakcji, 
> tylko dla większej korzystać z relacji?
Szybko... nie rozumiem wszystkich szczegółów. Możesz wkleić Twój bieżący
projekt tabel i zapytanie które wolno działa lub obawiasz się że
będzie wolno działało?


Pozdrawiam

W dniu 03.05.2016 o 13:14, M.M. pisze:
> Szybko... nie rozumiem wszystkich szczegółów. Możesz wkleić Twój bieżący
> projekt tabel i zapytanie które wolno działa lub obawiasz się że
> będzie wolno działało?

Jeszcze chciałem zapytać się o transakcje. Przypuszczam że należy dążyć 
do tego aby pomiędzy BeginTransaction a EndTransaction nie upływało zbyt 
wiele czasu, tylko atomowe operacje.
Tak jest gdy zapisuję transakcje.
Ale gdy jeszcze chcę zapisywać bloki, to czy muszę tworzyć jedną 
transakcję do zapisu wszystkich transakcji w bloku?
Bo w tabeli bloki mam na przykład ilość_transakcji, i to musi się 
zgadzać z tabelę transakcje.
A dla innych przykładów, gdzie jeszcze dłużej miała by działać jedna 
transakcja?

W dniu 03.05.2016 o 13:14, M.M. pisze:
> Po drugie, osobiście polecam zawsze zdefiniowanie klucza bigint
> jako klucza głównego w każdej tabeli, nawet jeśli istnieje 'naturalny
> klucz' typu pesel, albo Twój hash.

BigInt z autoinkrementacją? A może zamiast tego klucz na dwa pola int: 
numer bloku i numer transakcji w bloku - będzie po kolei.
A może tworzyć jeden większy numer: int numeru bloku + int transakcji w 
bloku = 64 bitowe?

On Tuesday, May 3, 2016 at 1:34:53 PM UTC+2, Borneq wrote:
> W dniu 03.05.2016 o 13:14, M.M. pisze:
> > Po drugie, osobiście polecam zawsze zdefiniowanie klucza bigint
> > jako klucza głównego w każdej tabeli, nawet jeśli istnieje 'naturalny
> > klucz' typu pesel, albo Twój hash.
> 
> BigInt z autoinkrementacją? A może zamiast tego klucz na dwa pola int: 
> numer bloku i numer transakcji w bloku - będzie po kolei.
> A może tworzyć jeden większy numer: int numeru bloku + int transakcji w 
> bloku = 64 bitowe?

Moim zdaniem to przekombinowanie, ale zdarzają się odmienne zdania.
Ja uważam, że klucz główny powinien być jedną kolumną typu int lub
bigint.

Pozdrawiam

On Tuesday, May 3, 2016 at 1:33:11 PM UTC+2, Borneq wrote:
> W dniu 03.05.2016 o 13:14, M.M. pisze:
> > Szybko... nie rozumiem wszystkich szczegółów. Możesz wkleić Twój bieżący
> > projekt tabel i zapytanie które wolno działa lub obawiasz się że
> > będzie wolno działało?
> 
> Jeszcze chciałem zapytać się o transakcje. Przypuszczam że należy dążyć 
> do tego aby pomiędzy BeginTransaction a EndTransaction nie upływało zbyt 
> wiele czasu, tylko atomowe operacje.
> Tak jest gdy zapisuję transakcje.
> Ale gdy jeszcze chcę zapisywać bloki, to czy muszę tworzyć jedną 
> transakcję do zapisu wszystkich transakcji w bloku?
> Bo w tabeli bloki mam na przykład ilość_transakcji, i to musi się 
> zgadzać z tabelę transakcje.
> A dla innych przykładów, gdzie jeszcze dłużej miała by działać jedna 
> transakcja?

Nic nie rozumiem.
Pozdrawiam

Masz tak definiować transakcje by działało.
By cofnięcie transakcji było skuteczne i nie spowodowało zepsucia spujności 
bazy.
Po to są transakcje.
Szybkością się nie pszejmuj w pszypadku transakcji,
bo spujność jest kluczowa nie szybkość, zwłaszcza pszy obecnym postępie.

-- 
(tekst bez: ó, ch, rz i -ii)
Ortografia to NAWYK, często nielogiczny, ktury ludzie ociężali umysłowo,
nażucają bezmyślnie następnym pokoleniom.