[siemanko]

#programowanie #java #bazydanych #sqlite

Jak ogólnie rozwiązuje się kwestie zapisu do bazy obiektów z dużą ilością pól. Gdzie dodatkowo ilość pól może ulegać zmianie.

Bo chyba nie bardzo dobrym rozwiązaniem byłoby tworzenie tabeli np z 50 kolumnami? Czy tutaj do akcji powinna wejść serializacja? Czy to wydajne?

[mathix]

@siemanko: Baza dokumentowa

[siemanko]

@mathix: tzn?

[m.....q]

chyba nie bardzo dobrym rozwiązaniem byłoby tworzenie tabeli np z 50 kolumnami?

@siemanko: Jesli jestem pewien ze to jest dobrze znormalizowany data model to dlaczego nie?

[a.....y]

@siemanko: na pewno przy 50 kolumnach masz dobrze znormalizowane? :/

[siemanko]

@msq: A co w przypadku gdy obiekt posiadający np 5 pól ma dodatkowo pole z tablicą obiektów, której wielkość jest różna? Czy dla tej tablicy należy tworzyć oddzielną tabelę? Czy w takim razie jeśli mam 1000 obiektów to dla tylu mam tworzyć oddzielne tabele?

[m.....q]

@siemanko: Nie ma w tym zadnego patternu? Definiujesz sobie tabele wszystkich mozliwych pol, kazde dostaje swoje ID, w aplikacji dobierasz pola ktore chcesz wyswietlic, w bazie zapisujesz ID....

Albo sprawdz pola typu SET lub ENUM, jesli to MySQL. Ma to swoje wady i zalety.

[G.....n]

@siemanko: a) normalizacja - można rozbić na wiele tabel

b) how about NoSQL?

[raczejNiekoniecznie]

A co w przypadku gdy obiekt posiadający np 5 pól ma dodatkowo pole z tablicą obiektów, której wielkość jest różna?

@siemanko:

Tabela MIKROBLOGER [login,

[siemanko]

@msq: Hmm... widzę będzie trochę z tym klepania, ale ufam, że to jedyne wyjście.

A co powiesz na taki przypadek:

item_Id | title | price | count | String[] <- jak załatwić sprawę tej tablicy? Oddzielna tabela? Czy

[siemanko]

@raczejNiekoniecznie: Musi być tylko i wyłącznie sqlite :/

[G.....n]

@siemanko: Sprecyzuj problem, bo widać, że robisz projekt na zaliczenie i prawdopodobnie źle formułujesz nam problem.

[raczejNiekoniecznie]

itemId | title | price | count | String[] <- jak załatwić sprawę tej tablicy? Oddzielna tabela? Czy serializacja?

@siemanko: Co rozumiesz pod pojęciem serializacji? Zebranie 10000 stringów w jeden wielki string? I to do jednej krotki? Słabo. Tworzysz oddzielną tabelę i w niej trzymasz pary itemId | string. Potem się zapoznajesz z operacją JOIN i problem rozwiązany.

[siemanko]

bo widać, że robisz projekt na zaliczenie

@Ginden: Heh, dla klienta :) Mam problem bo nigdy raczej nie spotkałem się z sytuacją tak skomplikowanych obiektów, które trzeba byłoby zapisać. Ogólnie walczę z allegro web api i ich poronionym pomysłem przedstawiania produktów. Chcę zapisywać obiekty, których jednym z pól jest ich FieldsValue[]

[G.....n]

@siemanko: No to jak wyżej - osobna tabela a potem JOIN.

[siemanko]

@raczejNiekoniecznie: Czyli jednak rozwiązanie oddzielna tabela dla każdego obiektu jest najlepsze? Tak pierwotnie sobie myślałem żeby to tak rozwiązać, ale obawiałem się o stosowanie złej praktyki i spadku wydajności.

@Ginden: Czyli widzę problem SOLVED :)

[m.....q]

@siemanko: Poczytaj troche o normalizacji w bazach danych bo niektore pytania sa z gatunku tych podtstawowych :)

Zserializujesz sobie to i jak chcesz to potem wyszkuiwac? Pelen skan tabeli, przeslanie wszystkiego do aplikacji w petli wyszukiwanie rekordow ktore Cie interesuja? Czy tez wywolywanie fukncji na kazdym rekordzie?

Nie idz ta droga, takie dane (zserializowane) mozesz sobie rownie dobrze trzymac w pliku tekstowym - uzytecznosc ich bedzie podobna a odpadnie Ci

[siemanko]

@msq: Ogólnie zamysł był taki, że te serializowane dane mały być tylko powiązane do danego rekordu. Wyszukuję np po ID_produktu i deserializuję tą tablicę.

Ale rozwiążę to tak jak radzicie, oddzielnymi tabelami.

Cały czas nosze się z nauką SQL i jakoś nie mogę się za to zabrać. Chyba czas najwyższy :)

Dzięki wszystkim za pomoc!

[m.....q]

Ogólnie zamysł był taki, że te serializowane dane mały być tylko powiązane do danego rekordu. Wyszukuję np po ID_produktu i deserializuję tą tablicę.

@siemanko: Wiecej niz pewne ze za pol roku przyjdzie klient i powie zebys mu zrobil tez wyszukiwanie po paramterach ktore sa zserializowane. I sie bedzie dziwil ze tokosztuje dwa dni pracy i ze trzeba czesc aplikacji i bazy przerobic :)

[siemanko]

@msq: No nie sposób się z tobą nie zgodzić :) Trzeba zawsze wybiegać wyobraźnią w przyszłość.