Piszę sobie dysk internetowy, coś jak google drive. Pliki będą przechowywane na dysku, natomiast informacje o pliku takie jak jego nazwa i tak dalej będą przechowywane w bazie danych (w tabeli files). Jeden użytkownik ma mieć możliwość wrzucenia maksymalnie tylko np. 1 GB danych (administrator będzie miał możliwość konfiguracji, będzie można ustawić w pliku konfiguracyjnym ile maksymalnie miejsca na dysku może zająć użytkownik). Dodatkowo chcę mieć możliwość wyświetlenia użytkownikowi rozmiaru każdego pojedyńczego pliku. Aby to zrobić muszę gdzieś zapisywać rozmiar plików. Wpadłem na następujące rozwiązania:

1. Przechowuję rozmiar każdego pojedyńczego pliku w bazie danych jako integer (w bajtach) w tabeli files, aby sprawdzić ile miejsca zajmuje dany użytkownik to liczę sumę rozmiarów wszystkich plików danego użytkownika odpowiednim zapytaniem MySQL (SELECT SUM(size) FROM files WHERE uid = 69, gdzie uid to ID użytkownika, do którego należą pliki a size chyba nie muszę tłumaczyć).

2. Przechowuję rozmiar każdego pojedyńczego pliku w bazie danych jako string (np. 21 KB, 148 GB, 71,21 MB) w tabeli files i dodatkowo przechowuję sumę rozmiaru wszystkich plików danego użytkownika jako integer w bajtach, w tabeli users.

3. Nie przechowuję rozmiaru plików w bazie danych, natomiast pobieram ją za każdym razem za pomocą PHP korzystając np. z DirectoryIterator. Musiałbym wtedy pobrać z bazy danych wszystkie pliki, które należą do danego użytkownika a potem przejechać przez nie DirectoryIteratorem. Moim zdaniem bez sensu.

Zastanawiam się, które rozwiązanie jest najbardziej optymalne i sensowne. A może macie jeszcze jakieś pomysły?

oczywiscie ze nr1. Skad pomysl na pozostale 2?

3 przecież nie jest złe. Katalogi mogłyby być id użytkownika. Wtedy tylko proste du na katalogu i jest rzeczywisty rozmiar.

Bezsensowne podejście, chcesz za każdym odświeżeniem "panelu" aby skrypt liczył rzeczywistą wartość? Jeżeli już musisz wykonać to w ten sposób to cacheuj tę wartość i odpalaj nowe cacheowania przy każdej akcji użytkownika takiej jak add/delete/update.

Nawet gdyby to było w ten sposób robione, to będzie i tak 1000x szybsze niż sumowanie na bazie. du będzie też wewnętrznie cache'owany przez system.

Jakim cudem nr3 ma byc szybsze od 1? Przeciez on w nr 3 pobiera wpierw z bazy liste wszystkich plikow...

Chcesz mi powiedzieć że zwykły SELECT sumujący jedną kolumnę będzie chodził wolniej niż DirectoryIterator?

A czy ja gdziekolwiek pisałem o DirectoryIterator?

Pisales o nr3, ktore to jest DirectoryIteratorem.
Fakt, wspomniales tez potem o du na folderze co zmienia postac rzeczy

Nie mniej jednak oryginalny nr3 jest do bani.
A i wartosci rozmiar plikow jest rownie dobrze trzymac w bazie tak jak trzymane beda nazwy

Nr 3 jest: np. z DirectoryIterator. Drobna różnica

Nadal uwazasz ze pobranie wszystkich plikow z bazy i potem sprawdzenie ich rozmiaru na dysku jest lepsze niz proste SUM na bazie?
To mam na mysli ze oryginalny nr3 jest do bani.

Też uważam, że nr 3 jest bez sensu. Waham się między 1 i 2, wszystko zależy od tego ile w bazie danych zajmuje VARCHAR a ile INT, przy czym maksymalna liczba jaką można zapisać na UNSIGNED INT to 4294967295, co oznacza, że pojedyńczy plik mógłby mieć rozmiar tylko 4 GB bo więcej mi się w bazie nie zmieści. Musiałbym użyć BIGINT, który zajmuje 8 bajtów. Zatem przy opcji nr 1 mam kolumnę o rozmiarze 8 bajtów dla każdego pliku. Przy opcji nr 2 muszę zrobić kolumnę BIGINT w tabeli users, która przechowuje sumę wszystkich rozmiarów pliku w bajtach oraz kolumnę VARCHAR(9) w tabeli files, która przechowuje rozmiar pojedyńczego pliku wraz z jednostką (np. "999,99 MB"). Zatem mam kolumnę o rozmiarze 8 bajtów dla każdego użytkownika plus +-9 znaków dla każdego pliku. Bazę mam kodowaną w UTF8 i o ile się nie mylę 1 znak zajmuje 1 bajt, więc VARCHAR(9) zajmuje +- 9 bajtów. To chyba opcja nr 1 będzie najbardziej rozsądna. Dobrze myślę? Pytanie też jak długi byłby czas wykonywania zapytania SELECT SUM(size) FROM files WHERE uid = 69 przy dużej ilości rekordów.

Alternatywą dla opcji 2 są dwa pola DECIMAL (XXX,XX) + TINYINT lub ENUM dla jednostki.

DECIMAL zajmuje chyba 8 bajtów (nie jestem pewny) a TINYINT i ENUM 1 bajt, co daje razem 9 bajtów. Wyjdzie na to samo co przy VARCHAR(9)

Jeśli dobrze liczę to DECIMAL(5,2) zajmie 5 bajtów.
Nie chcesz DECIMAL, to MEDIUMINT.

Ale macie dylematy....

Wpis w tabeli files unsigned int (co daje nam ~4GB pliki) - trzymasz rozmiar w bajtach.
Dodatkowo możesz pokusić się w tabeli users o sumę plików (ustawiasz trigger na BD w files co by dodawał/odejmował od sumy w users) i nawet nie musisz mielić tabeli files.

mielenie dyskiem jest bez sensu skoro można to załatwić optymalniej.

A co jeśli użytkownik zechce wrzucić plik, który zajmuje 5 GB ? Myślę, że BIGINT powinien być. A o triggerach poczytam, nie wiedziałem, że takie bajery można robić.

Toz sam napisales ze user bedzie mial limit na sume wszystkich 1GB a teraz nagle chcesz mu pozwolic na plik 5GB... Miejze litosc

Może być i BigInt, nie zrobi Ci to różnicy. Zawsze też możesz zaokrąglać rozmiary plików do pełnych KB dzięki temu zawsze to kilka bajtów do przodu

Nie prawda, napisałem:



Dobra, dzięki wszystkim za pomoc, chyba zdecyduję się na rozwiązanie Pyton_000.