ďťż
 
[MySQL] wektor wartosci jako typ danej? ďťż
 
[MySQL] wektor wartosci jako typ danej?
Zobacz wiadomości
 
Cytat
A gdyby tak się wedrzeć na umysłów górę, / Gdyby stanąć na ludzkich myśli piramidzie, / I przebić czołem przesądów chmurę, / I być najwyższą myślą wcieloną. . . Juliusz Słowacki, Kordian
Indeks BCB i MySQL subiekt gt fototapeta
 
  Witamy

[MySQL] wektor wartosci jako typ danej?



Tomasz Pyra - 11-01-2006 09:08
[MySQL] wektor wartosci jako typ danej?
  Czy da sie zadeklarowac typ danych trzymanych w jakiejs kolumnie tabeli
jako wertor (jednowymiarowa tablice) danych prostego typu?

Chodzi mi o to, zeby w jednym polu tabeli trzymac np. 30 floatow.

W mojej tabeli trzymam pewne dane pomiarowe. Teraz doszla mi kolejna
dana - a mianowicie histogram ktory sklada sie z 30-tu wartosci typu float.

Najprawdopodobniej dojdzie jeszcze kilka takich pol gdzie atomowa dana
jest cala salwa danych typu prostego. Nie ma sensu tworzenia dla takiej
danej trzydziestu pol typu float, bo tak na prawde nikogo nie interesuje
wartosc konkretnego pojedynczego slupka, a zawsze tylko calosc.

Najlepsze wydaje mi sie takie rozwiazanie, zeby jako typ kolumny tabeli
podac taka macierz o konkretnej dlugosci i za kazdym razem zapisywac i
odczytywac z tego pola cala zawartosc tego histogramu.

Krotki rzut oka na tutorial MySQL-a (byc moze za krotki) i nic nie
znalazlem na temat definiowania takiego typu.

Czy tak sie wogole da? Czy moj pomysl jest dobry? Moze lepiej to zrobic
w inny sposob?

Na pewno da sie dane trzymac w BLOB-ie, ale trace w ten sposob "tekstowa
przejzystosc", wchodze w problemy z kodowaniem danych liczbowych do
binarnych (problemy z little/big endian i jeszcze rozne inne).

Moglbym utowrzyc osobna tabele "histogramy" i w mojej glownej tabeli
trzymac tylko namiary na klucz tego histogramu.
Ale nie podoba mi sie trzymanie kazdego slupka histogramu w osobnym polu
tabeli - nie ma takiej potrzeby (ja wiec ze na jedno wychodzi) poniewaz
pobierane i ustawiane zawsze beda wszystkie jednoczesnie.
Pozatym komplikuje mi to nieco baze danych, uzycie relacji na pewno
obciazy bardziej silnik bazy danych, a zalezy mi tam rowniez na wydajnosci.
Komplikuje rowniez zapytania, a akurat chcialem zeby podstawowy
interfejs bazy danych (dopisywanie i odczytywanie tych pomiarow) byl
maksymalnie prosty, tak zeby osoba bez zbytenigo pojecia o bazach danych
dala sobie rade.





=?ISO-8859-2?Q?Pawe=B3_Matejski?= - 11-01-2006 09:08

  Tomasz Pyra wrote:
> Czy da sie zadeklarowac typ danych trzymanych w jakiejs kolumnie tabeli
> jako wertor (jednowymiarowa tablice) danych prostego typu?
>
> Chodzi mi o to, zeby w jednym polu tabeli trzymac np. 30 floatow.
>
>
> W mojej tabeli trzymam pewne dane pomiarowe. Teraz doszla mi kolejna
> dana - a mianowicie histogram ktory sklada sie z 30-tu wartosci typu float.
>
> Najprawdopodobniej dojdzie jeszcze kilka takich pol gdzie atomowa dana
> jest cala salwa danych typu prostego. Nie ma sensu tworzenia dla takiej
> danej trzydziestu pol typu float, bo tak na prawde nikogo nie interesuje
> wartosc konkretnego pojedynczego slupka, a zawsze tylko calosc.
>
>
> Najlepsze wydaje mi sie takie rozwiazanie, zeby jako typ kolumny tabeli
> podac taka macierz o konkretnej dlugosci i za kazdym razem zapisywac i
> odczytywac z tego pola cala zawartosc tego histogramu.
>
> Krotki rzut oka na tutorial MySQL-a (byc moze za krotki) i nic nie
> znalazlem na temat definiowania takiego typu.
>
> Czy tak sie wogole da? Czy moj pomysl jest dobry? Moze lepiej to zrobic
> w inny sposob?
>
> Na pewno da sie dane trzymac w BLOB-ie, ale trace w ten sposob "tekstowa
> przejzystosc", wchodze w problemy z kodowaniem danych liczbowych do
> binarnych (problemy z little/big endian i jeszcze rozne inne).
>
> Moglbym utowrzyc osobna tabele "histogramy" i w mojej glownej tabeli
> trzymac tylko namiary na klucz tego histogramu.
> Ale nie podoba mi sie trzymanie kazdego slupka histogramu w osobnym polu
> tabeli - nie ma takiej potrzeby (ja wiec ze na jedno wychodzi) poniewaz
> pobierane i ustawiane zawsze beda wszystkie jednoczesnie.
> Pozatym komplikuje mi to nieco baze danych, uzycie relacji na pewno
> obciazy bardziej silnik bazy danych, a zalezy mi tam rowniez na wydajnosci.
> Komplikuje rowniez zapytania, a akurat chcialem zeby podstawowy
> interfejs bazy danych (dopisywanie i odczytywanie tych pomiarow) byl
> maksymalnie prosty, tak zeby osoba bez zbytenigo pojecia o bazach danych
> dala sobie rade.

Może pomyśl o zmianie bazy danych?

--
P.M.




Tomasz Pyra - 11-01-2006 09:11

  Paweł Matejski napisał(a):

> Może pomyśl o zmianie bazy danych?

Raczej nie wchodzi to w gre.

W mojej bazie bede musial trzymac 2 rodzaje histogramow - 100 slupkowy i
30 slupkowy.

Bedzie takich po kilka w jednym rekordzie "pomiar". I
kilkanascie/kilkadziesiat takich dziennie.

Teraz widze 3 wyjscia:

1) tabela pomiar bedzie miala kilkaset kolumn w ktorych bede trzymal te
histogramy

2) stworze tabele "histogram100" i "histogram30", gdzie tabele beda
mialy odpowiednio 101 i 31 kolumn (dane+klucz), a w tabeli pomiary bede
trzymal tylko numer wiersza do tabel z histogramami.

3) stworze tabele "histogramy", gdzie bede mial 3 kolumny - numer
pomiaru, numer slupka i wartosc. A wiec chcac pobrac histogram z
jakiegos pomiaru, bede wysylal zapytanie o wszystkie dane z tabeli
histogramy gdzie numer pomiaru zgadza sie z tym ktory chce dostac, i
sortowal wedlug numeru slupka.

4) stworze tabele "histogramy" gdzie bede mial 12 kolumn. klucz, 10
kolumn z wartosciami kolejnych slupkow, i 11 ktora bedzie wskazywala na
klucz w tabeli histogramy ktory zawiera ciag dalszy histogramu.

widze takie wady:
1) kompletnie bez sensu

2) mimo wszystko nie podoba mi sie tabela ktora ma 100 kolumn (a co jak
nagle przyjda mi inne histogramy - 50 slupkow, 150 slupkow, a moze 10000
slupkow?)

3) niepotrzebny 3x wiekszy rozmiar i "wsteczna" relacja - chyba
strasznie dlugo sie to bedzie wyszukiwalo

4) Skomplikowane umieszczanie i pobieranie danych z takiej bazy.

Narazie sklaniam sie ku rozwiazaniu numer 2 (jezeli MySQL nie wspiera
typu z tablica danych).
Czy to rozwiazanie bedzie optymalne?
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • effulla.pev.pl
  • comp
    [mysql] =?ISO-8859-2?Q?Za=E6mienie=2E=2E=2E_jak_wy=B6wietli=E6?==?ISO-8859-2?Q?=2E=2E=2E?= [mysql] =?ISO-8859-2?Q?wielko=B6=E6_bazy_a_stabilno=B6=E6=2C?==?ISO-8859-2?Q?_podzia=B3_du=BFej_bazy_a_powi=B1zania_tabel?= [MySQL] =?ISO-8859-2?Q?Wy=B6wietlenie_kolejnej_pozycji=2C_?==?ISO-8859-2?Q?jak=B1_mia=B3by_dany_rekord=2C_gdybym_czyta=B3 _?==?ISO-8859-2?Q?wg_konkretnych_kryteri=F3w=2E_Da_si=EA_=3F?= [mysql 4.0.x] przenoszenie kolum =?ISO-8859-2?Q?mi=EAdzy_bazam?==?ISO-8859-2?Q?i_cd_=2E=2E=2E_?= [MySQL] =?ISO-8859-2?Q?z=B3=B1czenie_tabeli_u=BFytkownik_i?==?ISO-8859-2?Q?_zdj=EAcia_z_wyborem_zdj=EAcia_domy=B6lnego?= [MySQL] Jak =?ISO-8859-2?Q?wpisa=E6_do_tabeli_pozycje_dl?==?ISO-8859-2?Q?a_wierszy_gdybym_te_wiersze_wybiera=B3_w_ok?== ?ISO-8859-2?Q?re=B6lonej_kolejno=B6ci_=3F?= Gdzie MySQL 4.1, a gdzie 5.0? [MySQL 4.0...4.1] zabezpieczenie przed =?ISO-8859-2?Q?jednoczesn?==?ISO-8859-2?Q?=B1_edycj=B1?= [MS SQL] "set names" (mySQL) w MS SQL [mysql 5.x] jak =?ISO-8859-2?Q?zrealizowa=E6_zapytanie=3F_cz?==?ISO-8859-2?Q?yli_podzapytanie_i_wi=EAcej_ni=BF_jeden_rz=B1? ==?ISO-8859-2?Q?d_wynik=F3w?=
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • melooonka.opx.pl
  • Cytat

    Decede mihi sole - nie zasłaniaj mi słonca.
    Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
    Hoc fac - tak czyń.
    A tergo - od tyłu; z tyłu.
    I czarne włosy posiwieją. Safona

    Valid HTML 4.01 Transitional

    Free website template provided by freeweblooks.com