Zapis dokumentów do bazy Opcje

[gitbejbe]

Witam,

Jestem w trakcji projektowania aplikacji, w której użytkownik będzie mógł tworzyć i zapisywać różnego rodzaju dokumenty -np. do bazy danych. Zastanawiam się nad najlepszym sposobem składowania takich dokumentów. Muszę przewidzieć, że takich dokumentów będzie zapisywanych od groma. Zastanawiam się czy zwykła relacja jeden do wielu zda egzamin - czyli tablica ''użytkownik'' może mieć wiele dokumentów w tablicy ''dokumenty''. Dokument zapisywany byłby w polu BLOB jako zserializowany obiekt. Jeśli ktoś z was miał do czynienia z podobnym tematem, proszę o podpowiedź jak to zrobić najwydajniej. Przypomnę, że dokumentów będzie naprawdę masa i nie będę mógł ich usuwać.

[rad11]

Odrzuc BLOB zostan ninja. Skladuje sie tylko adresy do plikow.

[gitbejbe]

Dokument musi być zawsze gotowy do edycji. Stąd też nie widzę sensu przechowywanie dokumentów w plikach. Generowanie do np pdf dzieje się w locie na żądanie klienta. Jeśli jest lepszy sposób, to czekam na pomysły

[kartin]

Dokument czyli plik, jak sama nazwa mówi najlepiej przechowywać jako plik a w bazie danych ścieżkę/nazwę tego pliku.
Jeśli użytkownik może mieć wiele dokumentów, a dokument należy tylko do jednego użytkownika to relacja jeden do wielu nadaje się.

Jeśli dokument przechowywany w bazie jest "zawsze gotowy do edycji" to przechowywany jako plik również - w obu przypadkach najpierw musisz dokonać odczytu dokumentu z bazy lub z pliku.

Ten post edytował kartin 3.06.2015, 18:11:23

[gitbejbe]

w takim razie jak najlepiej jest zapisać informacje o dokumencie w pliku ? Trzymać np w XML'u ? Kolejne pytanie jak wyglądałaby struktura folderów do przechowywania tych plików ? Pomyślałem aby utworzyć w takim razie folder usera i do niego wrzucać jego dokumenty:

[HTML] pobierz, plaintext 
-> Dokumenty
    -> rok (rok zarejestrowania użytkownika)
         -> miesiąc (miesiąc zarejestrowania użytkownika)
             -> dzień (dzień rejestracji użytkownika)
                 -> login (login użytkownika)
                     -> dokumenty
                        -> rok (rok wygenerowania dokumentu)
                          -> miesiąc (miesiąc wygenerowania dokumentu)
                             -> dzień (dzień wygenerowania dokumentu)
                                - dokument 1
                                - dokument 2
                                - ...
[HTML] pobierz, plaintext 

Ten post edytował gitbejbe 3.06.2015, 18:23:03

[kartin]

Możesz trzymać w XML, JSON czy nawet jako serializowane zmienne, o ile taka metoda wynika jakiejś potrzeby. Jeśli nie istnieje specjalna potrzeba to należy stosowac proste metody, lepiej będzie przechowywać każdą informację w osobnej kolumnie. Chyba, że lista informacji o plikach nie jest stała lub z góry znana to wtedy można w dodatkowej tabeli.

Może być i tak struktura może być również i inna to nie jest kluczowe. Byle nie wszystkie dokumenty w jednym katalogu. Jeśli w katalogu dokumenty nie będzie nic innego niż katalogi z latami to usunąłbym to zbędne zagłębienie.

[redeemer]

A może warto zainteresować się bazami NoSQL. Np. MongoDb

[gitbejbe]

Dokument generowany jest na podstawie różnych formularzy na stronie. Sądzę, że łatwiej będzie zapisać te dane z formularza do pliku XML, JSON ... obojętnie, tak aby w razie edycji mógł łatwo to wczytać na stronie i nadpisać ponownie w przypadku edycji. Drukowanie pliku końcowego np do PDF, robione byłoby w locie na żądanie użytkownika. Pytanie tylko czy lepiej trzymać to wszystko w bazie czy tak jak wspomnieliście - w plikach. Użytkownik będzie miał panel do przeglądania listy swoich dokumentów, która dodatkowo wyświetlać będzie ich podstawowe informacje. Tak czy siak dane skądś trzeba odczytać, pytanie skąd lepiej szybciej i łatwiej.

@redeemer, zostanę jednak przy relacjach- nie lubię kombinować, tym bardziej, żę logika aplikacji przy zastosowaniu noSQL narzuciłaby masę dodatkowego kodu aby był ład i skład.

Ten post edytował gitbejbe 3.06.2015, 18:59:21

[kartin]

Czyli tak naprawdę nie będzie przechowywania żadnych dokumentów rozumianych jako pliki programów biurowych + pliki pdf, a jedynie informacji tekstowych wpisanych w różne pola formularza na stronie? Jeśli tak to przechowywanie tych informacji w bazie danych nie jest złym pomysłem, wręcz odwrotne.

Oczywiście konwersja całej tablicy $_POST do JSON i zapisanie w jednej kolumnie w bazie będzie prostsza niż zapisywanie każdego pola formularza w osobnej kolumnie, tylko kwestia tego czy jest to właściwe rozwiązanie. Jeśli żadne z tych informacji nie będą wykorzystywane w innym celu niż wczytanie do formularza, zapis z powrotem i przygotowanie pdf (czyli np. nie będzie wyszukiwania po wartości konkretnego pola, lub listingu kilku wybranych pól) to myślę, że można pozwolić sobie na takie uproszczenie.

[gitbejbe]

Zgadza się. Wyszukiwanie będzie odbywało się (tak obecnie sądzę), tylko po dacie, ID, i ID_użytkownika - zazwyczaj to wystarcza. Oczywiście przy wyświetlaniu listy takich dokumentów, będę musiał wyświetlić dla każdego z nich kilka istotnych informacji które odpowiednio wybiorę w pętli z danych zapisanych z kolumny BLOB. To chyba lepsze rozwiązanie niż tworzyć X kolumn tylko po to aby mieć te informacje do wyświetlenia pod ręką - tym bardziej, że ilość tych ważnych informacji do wyświetlenia może ulec zmianie w wyniku dalszego rozwoju apki. Ale jak ma się dalej sprawa przechowywania wszystkich dokumentów wszystkich użytkowników w tej samej tabeli ? Totalnie śmierdzi to katastrofą na dłuższą metę.

[kartin]

Przy założeniu, że masz np. 10 pól a w listingu "dokumentów" potrzebujesz odczytać 2 pola to przy trzymaniu wszystkiego w jednej kolumnie 80% danych odczytanych z bazy jest zbędnych. Niepotrzebnie zwiększasz odczyt i transfer z bazy danych, a to jest błąd. Obstawałbym przy trzymaniu każdego pola w osobnej kolumnie, żadnego JSON czy XML. Dodatkowo konwersja danych do JSON a tym bardziej XML daje dodatkowy narzut w rozmiarze danych.
Login, hasło i ewentualnie inne dane o użytkowniku też trzymasz łącznie np. w JSON w jednej kolumnie? Widziałeś aby w napisanych zgodnie ze sztuką systemach ktoś tak robił?

Co ma prowadzić do katastrofy? Baza danych jest od przechowywania informacji, a backupy i tak trzeba robić oraz właściwie przechowywać.
Przy założeniu, że użyjesz bazy MySQL zainstalowanej na Linuksie a tabele będą trzymana na systemie plików ext3 lub ext4 to tabela może zajmować max 4 TB, a to powinno chyba wystarczyć.

Należy pamiętać o limicie 65535 bajtów na wiersz.

[gitbejbe]

Ok, dzięki za podpowiedzi : ) Temat do zamknięcia.

[redeemer]

To co wymyślacie i o czym piszecie rozwiązują właśnie bazy NoSQL (m.in. dynamiczny schemat "tabeli"/dokumentu), ale co ja tam wiem.

Ten post edytował redeemer 5.06.2015, 08:03:44