Wszystkiemu winna szuflada

Tworząc projekty do szuflady może pojawić się problem, skąd i jak wygenerować zawartość. Chociaż kilku użytkowników, chociaż kilka wpisów, kilka słów, dzięki czemu można zobaczyć jak system będzie wyglądać gdy ktoś będzie z niego korzystać.

Pisałem wcześniej o generatorze losowych danych Faker (http://jaroslawstadnicki.pl/2015/04/generator-danych-faker/). Nadal z niego korzystam, dzięki temu w stosunkowo krótkim czasie byłem w stanie wygenerować całkiem sensowną, pod względem ilości – nie jakości, bazę danych na której pracuję.

Tests controller

W projekcie posiadam specjalny kontroler, z którego zarządzam generowaniem losowych (lub pseudo losowych) danych.

Zrzut z kontrolera tests i widoczne dostępne opcje. Widać, ze mogę tworzyć użytkowników, duplikować kanały, tworzyć subskrypcje, dodawać elementy do przeczytania, generować wydarzenia, czy wreszcie naprawiać problemy, które wynikają, że mojego lenistwa.

Co mi to daje? Otóż wygenerowałem sobie bazę, która aktualnie ma 1.1 gigabajta, a składa się na to:

Co w tym ciekawego? Otóż mam tylko jednego aktywnego/prawdziwego użytkownika (to ja – taram), reszta to wytwór wyobraźni fakera. Część kanałów została zaimportowana z mojego feedly, inne natomiast to duplikaty, o zmienionej nazwie, lub zaciągnięte gdzieś z dostępnych list rss. O FeatureRequests pisałem wcześniej: http://jaroslawstadnicki.pl/2016/04/feature-request-jak-to-ugryzc/. Zostają już tylko jakieś subskrypcje kanałów dla sztucznych klientów, ich sztuczna aktywność (EventRssVieweds) oraz ich pojedyncze wpisy, które powinni przeczytać. Na koniec to z czym walczę aktualnie, czyli subskrypcje dla aktywności użytkowników.

Co z tego dla mnie

Po co to wszystko? Wcześniej pisałem o obowiązkowej konfiguracji entity framework (http://jaroslawstadnicki.pl/2016/03/entity-framework-obowiazkowa-minimalna-konfiguracja/) gdzie w komentarzach były różne zdania na ten temat, natomiast padło stwierdzenie, że nigdy nie pojawi lub nie powinien pojawić się w kodzie taki kod:

db.MojeEncje.ToList()

I teraz, taki kod nie pojawi (nie powinien) się pojawić gdy masz danych dużo. U mnie gdy robiłem wpis było tego malutko. Gdy wygenerowałem ich trochę, taki zapis zaczyna dopiero nabierać znaczenia. To nie znaczy, że wtedy nie byłem świadomy konsekwencji, wtedy mogłem sobie na to jeszcze pozwolić. Teraz powoli zaczyna mnie to boleć. Ale jeszcze nie na tyle, aby to zmieniać.

To dzięki takiej ilości danych, zaczynają się pojawiać problemy o których się nie myślałem wcześniej: stronicowanie, filtrowanie, projekcja danych na poziomie orm. czy sam orm jest mi potrzeby, czy automapper da rade, czy tyle warstw jest mi potrzebnych,… inne do których jeszcze nie doszedłem. Znowu część rzeczy wynikać będzie z chęci poprawy wydajności samej aplikacji, inne z użyteczności aplikacji.

O co mi chodzi?

Wygenerujcie sobie dane testowe, niech to będzie Jan Kowalski1234123141231231, niech czyta Lorem Ipsum12312312312, po tysiąc razy, niech zapcha bzdurami waszą bazę danych, albo niech nie posiada nic, taki null-user-object, albo niech posiada jeden wpis – bo nigdy nie wiecie, kto będzie waszym klientem. Zróbcie bazę danych która ma kilka giga i zobaczcie jak sobie radzie gdy danych jest więcej aniżeli kilka.