Arkusze kalkulacyjne – Excel, Arkusze Google lub arkusz o dowolnej innej nazwie – to naprawdę fajne i potężne narzędzia. Ale tak samo są z bazami danych. Kiedy należy trzymać się arkusza kalkulacyjnego? Kiedy należy przejść do bazy danych?
Do podobnych celów możesz używać arkuszy kalkulacyjnych i baz danych. Biorąc pod uwagę, że zarówno porządkują dane, jak i ułatwiają raportowanie, czasami może być trudno określić, który z nich jest najlepszy. Porozmawiajmy więc o zaletach i wadach każdej opcji.
Na początku…
Jeśli dopiero zaczynasz działalność, arkusz kalkulacyjny (lub „arkusz”) jest prawie zawsze Twoim pierwszym wyborem. Startupy rzadko mają budżet na obsługę bazy danych na zamówienie. A poza tym Twoja firma jest nowa; nie będziesz miał pojęcia, czy pozostanie mały, rozwinie się w wielką korporację, czy będzie gdzieś pośrodku.
Innym czynnikiem jest to, że struktura i organizacja Twojej firmy prawdopodobnie będą się zmieniać wraz z rozwojem. Tak naprawdę budowanie bazy danych na początku nie jest powszechną opcją. Tutaj zwykle wskakują arkusze.
Najważniejszym powodem korzystania z arkuszy jest to, że są one dostępne. Wystarczy kilka kliknięć, aby zacząć korzystać z programu Microsoft Excel, Arkuszy Google lub dowolnego innego programu do obsługi arkuszy kalkulacyjnych. Nie musisz planować skomplikowanej struktury; możesz po prostu wprowadzić swoje dane, wykonać obliczenia i raporty oraz udostępnić informacje współpracownikom. Arkusze oferują wiele fajnych wbudowanych funkcji i mogą przez dłuższy czas przejrzeć małą firmę.
Załóżmy, że masz wszystkie swoje dane w arkuszach. Dlaczego warto rozważyć budowę bazy danych? Innymi słowy, po co komplikować swoje życie, jeśli wszystko działa?
W tym momencie proponuję zadać sobie pytanie, jak dobrze wszystko działa. Pamiętaj, wszystko działa dobrze, dopóki nie przestanie działać. W przypadku arkuszy, im więcej masz danych, tym więcej problemów możesz napotkać. W jaki sposób bazy danych pomagają uniknąć tych problemów? A kiedy powinieneś rozważyć zmianę?
Korzystanie z arkuszy kalkulacyjnych do organizowania danych
Załóżmy, że założyliśmy firmę, która świadczy klientom usługi telekomunikacyjne i internetowe. Musimy śledzić, który klient aktualnie subskrybuje którą usługę. Klienci mogą mieć więcej niż jedną aktywną usługę na raz, a usługa może wygasnąć po upływie określonego okresu lub odnowić się automatycznie.
Przyjrzyjmy się rozwiązaniu wykorzystującemu arkusze.
Po prostu sporządziliśmy listę wszystkich danych, które posiadamy, tj. w jednym miejscu znajduje się mieszanka danych. Mamy dane klientów (kolumny od A do E), typy usług (kolumna F) i szczegóły usług (kolumny G, H i J).
Na pierwszy rzut oka wszystko wygląda całkiem nieźle. Możemy przeglądać wszystkie dane bez wykonywania skomplikowanych czynności. Możemy filtrować potrzebne nam dane i tworzyć tabele przestawne lub wykresy do celów raportowania. Jak dotąd tak dobrze.
Ale jeśli nadal będziemy używać arkuszy, gdy zdobędziemy więcej klientów, możemy osiągnąć punkt, w którym wszystko stanie się zbyt duże, aby arkusze mogły sobie z nimi poradzić. A to przynosi nowy zestaw problemów.
Potencjalne problemy z arkuszami kalkulacyjnymi
W porównaniu z arkuszami kalkulacyjnymi bazy danych są skomplikowane. Ale te „komplikacje” służą użytecznemu celowi; zapobiegają lub przynajmniej minimalizują następujące problemy:
Jakość danych
Jakość i spójność danych to ogromny problem w przypadku większych arkuszy. Chociaż zamierzamy prawidłowo przechowywać dane, problemy z jakością danych są bardzo powszechne. Ludzie popełniają błędy lub mamy nieoczekiwane informacje do wprowadzenia. Pomyśl tylko, jak poniższe scenariusze mogą stanowić problem:
- Chcemy dodać nowego klienta bez określania jego rodzaju usługi. Czy powinniśmy dodać dane klienta i pominąć szczegóły usługi? Jeśli możemy wstawić tylko klientów, którzy mają szczegóły usługi, jest to nieprawidłowa wstawka .
- Co się stanie, jeśli dodamy dane usługi, gdy staną się one dostępne po utworzeniu rekordu klienta?
- Co się stanie, jeśli klient zasubskrybuje wiele usług? Czy powinniśmy utworzyć nowy rekord dla każdej usługi, skoro możemy mieć tylko jeden typ usługi na rekord?
- Co się stanie, jeśli mamy wiele rekordów dla jednego klienta i musimy zaktualizować informacje o tym kliencie? Jeśli nie zmienimy informacji we wszystkich odpowiednich wierszach, nasze dane będą niespójne. Możemy mieć dwa różne adresy dla tego samego konta; w takich okolicznościach, skąd możemy wiedzieć, które dane są prawidłowe?
- Co się stanie, gdy usuniemy dane? Jeśli usuniemy cały wiersz, stracimy wszystkie dane tego klienta. To nie jest dobry pomysł; lepiej usunąć tylko dane usług i zachować dane klientów. Ale jak możemy to zrobić, jeśli wszystko jest przechowywane razem w jednym rzędzie?
- Co się stanie, jeśli tylko jeden klient zasubskrybuje usługę, a my usuniemy ten rekord? Jeśli usuniemy rekord tego klienta, czy usuwamy również cały rekord tej usługi? (Nazywa się to usuniętą anomalią .) Czy to oznacza, że nie oferujemy już tej usługi? Jeśli nadal ją oferujemy, straciliśmy wszystkie parametry związane z tą usługą.
Oczywiście będą komplikacje w przechowywaniu danych dla każdej firmy. Wszyscy mieliśmy problemy z jakością danych – m.in. otrzymaliśmy rachunki za usługi, których nie zamówiliśmy, obciążono nas dwukrotnie za tę samą rzecz lub wysłano paczkę na zły adres. Takie rzeczy się zdarzają i na małym zestawie danych stosunkowo łatwo je naprawić. Ale co się dzieje, gdy mamy tysiące, a nawet miliony wierszy? Wkrótce poświęcimy prawie cały nasz czas na rozwiązanie tych problemów.
Problemy z wydajnością
Problemy z wydajnością zdarzają się, gdy zestawy danych stają się zbyt duże, aby arkusz mógł efektywnie obsługiwać. Problemy z jakością danych wystąpią znacznie wcześniej niż problemy z wydajnością, ale to nie znaczy, że problemy z wydajnością są nieistotne. Au contraire; problemy z wydajnością mogą być nawet bardziej niebezpieczne niż problemy z jakością danych.
Powszechne jest wyszukiwanie określonych wierszy, wstawianie nowych wierszy, aktualizowanie lub usuwanie wartości komórek w istniejących wierszach oraz usuwanie całych wierszy. Wszystkie te działania wymagają dużo filtrowania, co nie stanowi problemu na małym zbiorze danych. Ale kiedy twoje arkusze stają się naprawdę duże, nawet prosta operacja może zająć kilka minut. Spędzanie połowy dnia pracy w oczekiwaniu, aż filtr wykona swoją pracę, nie jest mądrym wyborem.
Istnieje również powiązany problem redundancji – wielokrotne przechowywanie tych samych danych na dysku (np. dane klientów są przechowywane w kółko w wielu wierszach). Będzie to miało również wpływ na wydajność.
Na przyzwoitym sprzęcie arkusze z tysiącami rzędów będą w porządku. Ale kiedy wejdziesz w dziesiątki tysięcy rzędów, problemy z wydajnością mogą podnieść ich brzydkie głowy. Nie trzeba dodawać, że arkusze zawierające setki tysięcy, a nawet miliony wierszy będą miały wyjątkowo słabą wydajność.
Z drugiej strony bazy danych służą do rozwiązywania problemów z wydajnością. Gdy wszystko jest prawidłowo skonfigurowane, praca z milionami wierszy nie będzie stanowić żadnego wyzwania.
Zarządzanie danymi i raportami historycznymi
Jeszcze jednym ważnym problemem związanym z arkuszami jest śledzenie zmian danych w czasie. Jeśli po prostu usuniesz dane z arkuszy, stracisz je. Jeśli zdecydujesz się przechowywać arkusz dzienny (aby uchwycić wszystkie zmiany i zachować dane historyczne), wkrótce zostaniesz pochowany pod tonami arkuszy. Tworzenie raportów z takiej struktury jest naprawdę czasochłonne, a jakość generowanych z niej raportów byłaby bardzo wątpliwa.
Czy masz takie problemy z danymi?
W dzisiejszym artykule omówiliśmy niektóre wady korzystania z arkuszy do organizowania dużej ilości danych. Czy kiedykolwiek doświadczyłeś któregokolwiek z tych problemów? Czy jesteś gotowy, aby przenieść swój biznes na wyższy poziom? Jeśli odpowiedź brzmi „tak”, jesteś we właściwym miejscu! W przyszłym tygodniu dowiemy się, jak baza danych rozwiązuje problemy z przechowywaniem danych w arkuszach.
