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ć.

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

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

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.

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 

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.

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

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.

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.

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ę.

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.

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

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.