Dane URI vs. Binary w bazie danych

Question

Publikuję obraz na serwerze przy użyciu identyfikatora URI DANYCH (strona klienta, używając obszaru roboczego). Mam teraz dwie możliwości: mogę zapisać "obraz" jako ciąg w kolumnie varchar (max) lub mogę go przekonwertować na bajt [] i zapisać jako varbinary (max).

Jeśli chodzi o wykonanie, nakład jest taki sam. Próbuję określić, co byłoby bardziej efektywne, jeśli chodzi o 1: przestrzeń w DB i 2: wyświetlanie obrazu. Czy ktoś widział jakiekolwiek analizy na ten temat lub ma dobry sposób na zmierzenie tego?

AN FYI - obraz 3kb ma około 100K znaków w DB.

Zastosowanie: ASP.NET 4.5, MVC, SQL Server 2008

do wyjaśnienia

mogę albo zapisać obraz w bazie danych za pomocą byte [] w varbinary (MAX) kolumna jak jest Zwykle tak, lub mogę przechowywać identyfikator URI danych z płótna HTML5, który wygląda jak: dane: image/png; base64, iVBORw0K ... w kolumnie varchar (max).

Przechowywanie bajtu [] jest typowe i nie wymaga dalszych wyjaśnień. Przechowywania danych URI jest po prostu ciągiem i wyświetlania obrazu byłaby kwestia:

<img src="data:image/png;base64,iVBORw0K" /> or 
<img src="@Model.Uri" /> 

Moje pytanie brzmi, który z nich jest bardziej wydajnych i Oszczędność miejsca, a jeśli nie ma żadnej dokumentacji, białego papieru lub analizę wokół tego konkretnego porównania .

Answer 1

Bez prawdziwej odpowiedzi i niewielkiej ilości informacji Znalezienie się z Google, zrobiłem prosty test czasowy, wstawiając rekordy 20K (mniej niż to było bezcelowe) i wybierając jeden rekord na raz w pętli. Użyłem PetaPoco do dostępu do DB. Jeśli znajdziesz coś tam lub masz jakieś informacje, udostępnij je. Myślę, że będzie to częstszy scenariusz, w którym DATA URI przyciągnie więcej uwagi.

URI było konsekwentnie szybsze wstawianie i wybieranie. Szybszy jest względny, ponieważ jest mierzony w milisekundach. To nie powinno być czynnikiem - to cokolwiek jest łatwiejsze.

Jeśli chodzi o rendering do klienta. Użyłem dwóch metod, ImageResult (niestandardowy ActionResult, który zwraca obraz) z metody działania MVC (to renderuje obraz w odpowiedzi http) i zwraca ciąg URI i używa go jako obrazu SRC (tj. Src = "@ Model.Uri "). Znowu ledwie różnica. Wyniki z wykorzystaniem narzędzi dev Chrome:

ImageResult: 2 requests, 200ms, 3.2KB 
DATA URI: 2 requests, 200ms, 3.9KB 

Jednak zauważyłem, że ImageResult (byte []) wersja zostanie automatycznie buforowane przez przeglądarkę, bo to obraz dla wszystkich zamiarów i celów. Wersja URI DATA nie buforuje automatycznie przeglądarki.

Z tego podstawowego testowania wynika, że ​​bajt [] jest sposobem, aby przejść z powodu automatycznego buforowania przez przeglądarkę i wszystkie inne wyniki są równe.

My Set Up: i7, 8GB RAM, SSD, SQL Server 2012, IIS ekspresowe

korzyści buforowanie było coś zauważyłem, bez instalacji. Tak, jestem pewien, że można zarządzać nagłówkami HTTP, etag, buforowaniem danych wyjściowych itp.