Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [PHP][MySQL] Przechowywanie rozmiaru pliku
Forum PHP.pl > Forum > PHP
krzywy5830
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?
nospor
oczywiscie ze nr1. Skad pomysl na pozostale 2?
viking
3 przecież nie jest złe. Katalogi mogłyby być id użytkownika. Wtedy tylko proste du na katalogu i jest rzeczywisty rozmiar.
Puszy
Cytat(viking @ 10.01.2017, 14:48:09 ) *
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.
viking
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.
nospor
Jakim cudem nr3 ma byc szybsze od 1? Przeciez on w nr 3 pobiera wpierw z bazy liste wszystkich plikow...
Puszy
Cytat(viking @ 10.01.2017, 15:16:19 ) *
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.


Chcesz mi powiedzieć że zwykły SELECT sumujący jedną kolumnę będzie chodził wolniej niż DirectoryIterator?
viking
A czy ja gdziekolwiek pisałem o DirectoryIterator?
nospor
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
viking
Nr 3 jest: np. z DirectoryIterator. Drobna różnica wink.gif
nospor
Cytat
Musiałbym wtedy pobrać z bazy danych wszystkie pliki, które należą do danego użytkownika a potem przejechać przez nie DirectoryIteratorem.

Nadal uwazasz ze pobranie wszystkich plikow z bazy i potem sprawdzenie ich rozmiaru na dysku jest lepsze niz proste SUM na bazie? wink.gif
To mam na mysli ze oryginalny nr3 jest do bani. wink.gif
krzywy5830
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.
trueblue
Alternatywą dla opcji 2 są dwa pola DECIMAL (XXX,XX) + TINYINT lub ENUM dla jednostki.
krzywy5830
Cytat(trueblue @ 10.01.2017, 17:11:23 ) *
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) tongue.gif
trueblue
Jeśli dobrze liczę to DECIMAL(5,2) zajmie 5 bajtów.
Nie chcesz DECIMAL, to MEDIUMINT.
Pyton_000
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.
krzywy5830
Cytat(Pyton_000 @ 10.01.2017, 20:07:00 ) *
Wpis w tabeli files unsigned int (co daje nam ~4GB pliki)


A co jeśli użytkownik zechce wrzucić plik, który zajmuje 5 GB tongue.gif? Myślę, że BIGINT powinien być. A o triggerach poczytam, nie wiedziałem, że takie bajery można robić.
nospor
Toz sam napisales ze user bedzie mial limit na sume wszystkich 1GB a teraz nagle chcesz mu pozwolic na plik 5GB... Miejze litosc tongue.gif

Pyton_000
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 biggrin.gif
krzywy5830
Cytat(nospor @ 11.01.2017, 11:00:05 ) *
Toz sam napisales ze user bedzie mial limit na sume wszystkich 1GB a teraz nagle chcesz mu pozwolic na plik 5GB... Miejze litosc tongue.gif


Nie prawda, napisałem:

Cytat(krzywy5830 @ 10.01.2017, 11:58:43 ) *
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)


Dobra, dzięki wszystkim za pomoc, chyba zdecyduję się na rozwiązanie Pyton_000.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.