Grafowe bazy danych - jak naprawdę mogę ich użyć w realnym świecie?
Ostatnio dużo słyszymy o grafowych bazach danych. I choć ten typ bazy danych nie jest nowy, przykłady użycia są ciąle te same. Najczęściej są to artykuły- wypełniacze potrzebne do promocji treści wiec nie pisane przez osoby które naprawdę używają grafowych baz danych.
W tym artykule chcemy podzielić się z Wami przykładami użycia w realnym świecie, w firmach dużych i całkiem małych. Gdzieś na końcu powiemy że takie bazy danych są fantastyczne w podpowiadaniu kto jeszcze jest przyjacielem Klary i który bank jest zamieszany w pranie pieniedzy ale, nie oszukujmy się, wiekszość z Was nigdy nie będzie mieć takich potrzeb. Jak najbardziej będzie jednak chcieli się dowiedzieć które produkty zarekomendować klientom by zwiększyć sprzedaż, dotrzeć szybko do informacji, nie zgubić orientacji w aktywnościach klientów, dokonać obliczeń zdecydowanie szybciej niż to robisz teraz.
Obliczenia
Choć praktycznie wszystko co jest możliwe do zrobienia w grafowej bazie danych, jest także możliwe do wykonania w relacyjnej, grafowe robią wiele takich obliczeń zdecydowanie szybciej. Np. wyobraź sobie zapytanie MySQL które oblicza percentyl lub medianę cen produktów. Możesz? A teraz napisz takie zapytanie i zmierz ile czasu czekasz na jego wykonanie. Nawet nie musisz - nie będą to milisekundy. A w grafowej bazie danych, np Neo4j, będą. Tak więc jeśli np. budujesz funkcję która w programie wyświetli sugerowaną cenę przy tworzeniu oferty, użyj raczej grafowej bazy danych niż relacyjnej. Nie chodzi tu zresztą tylko o czas dostarczenia danych. Same zapytanie będzie prostsze, a baza posiada już gotowe funkcje. Czego nie możesz powiedzieć o wielu relacyjnych bazach danych - by np. wyliczyć percentyle trzeba wykonać wiele linijek kodu i poskładać rezultaty tych obliczeń.
Camunda BPM - aktywacja HTTP Basic Authentication
Interfejs API REST Camundy posiada uwierzytelnienie podstawowe HTTP (HTTP Basic Authentication). Domyślnie ta autentykacja jest wyłączona, ale można ją aktywować, dodając filtr serwletu Tomcat w następujący sposób:
<!-- Http Basic Authentication Filter -->
<filter>
<filter-name>camunda-auth</filter-name>
<filter-class>
org.camunda.bpm.engine.rest.security.auth.ProcessEngineAuthenticationFilter
</filter-class>
<async-supported>true</async-supported>
<init-param>
<param-name>authentication-provider</param-name>
<param-value>org.camunda.bpm.engine.rest.security.auth.impl.HttpBasicAuthenticationProvider</param-value>
</init-param>
<init-param>
<param-name>rest-url-pattern-prefix</param-name>
<param-value></param-value>
</init-param>
</filter>
Ten filtr znajduje się już w pliku 'camunda-bpm-tomcat-X.XX.X\server\apache-tomcat-X.X.XX\webapps\engine-rest\WEB-INF\web.xml', wystarczy go odkomentować w tym pliku.
Camunda BPM - zmiana domyślnej bazy H2 na MySQL
Domyślnie Camunda skonfigurowana jest by używać bazy H2. Czym jest baza H2. To lekka, napisana w Java baza która zajmuje (bez danych) tylko około 2MB na dysku. Ale ilość danych które może obsłużyć jest imponująca - maksymalnie 18446744073709551616 rekordów w tabeli. Idealnie nadaje się więc do różnego rodzaju projektów jako "domyślna baza", uruchamiana w produkcjach w wersji demo - uruchamiasz produkt a baza razem z nim. Możesz połączyć się z bazą H2 Camundy wpisując w przeglądarce http://localhost:8080/h2/h2 - użytkownik 'sa' bez hasła (pozostaw domyślne ustawienia w oknie logowania).
Camunda zaleca zmianę bazy danych na inną jeśli oprogramowanie ma być wykorzystywane produkcyjnie. Camunda ma gotowe skrypty by utworzyć strukturę bazy danych dla następujących baz danych: cockroachdb, db2, mariadb, oracle, postgres. Każdy więc odnajdzie się tutaj ze swoją ulubioną bazą danych. My pokażemy jak skonfigurować Camundę do pracy z MySQL.
Oracle Apex - przechowywanie danych w tabeli Oracle w formacie JSON
Jeśli wykorzystujemy tabele bazy danych do przechowywania ustawień aplikacji, często dochodzimy do momentu kiedy ilość pól jest niewystarczająca i musimy dodać kolejne pole. A z drugiej strony mamy parametry które nie potrzebują takiej ilości pól. Mamy też sytuacje kiedy nigdy nie wiemy ile pól będziemy potrzebować dla jakiegoś parametru. Rozwiązaniem tego formatu jest JSON. W jednym polu możemy przechować praktycznie każdą strukturę, każde ustawienia.
Tworzenie w tabeli Oracle pola typu JSON i używanie JSON w celu przechowania informacji.
Oracle nie posiada gotowego pola typu JSON. Takim formatem może być VARCHAR2 (limit znaków) CLOB lub BLOB jeśli przechowujesz dane binarne i nie chcesz niepożądanej konwersji znaków. Tabelę możesz utworzyć używając SQL Developer, możesz użyć też opcji SQL Workshop w Oracle Apex i wklejając odpowiednie komendy SQL. Jednak Oracle Apex oferuje wygodne GUI ktore przeprowadzi Cie przez cały proces. Więcej, nie musisz zawracać sobie głowy indeksami, atutomumeracją, trigerami. Zacznij więc od stworzenia tabeli. Powiedzmy że będzie mieć pola:
ID: number
APP_PARAM: varchar2(50)
PARAM_VALUE: clob
Pole 'param_value' będzie przechowywać ustawienia w formacie JSON. Póki co to pole jest po prostu polem typu CLOB - przyjmie każdą wartość. My chcielibyśmy jednak by akceptowało tylko JSON - da to nam pewność że ciąg znaków który się tam znajdzie rzeczywiście jest formatu JSON. Poniższą komendą zapewnimy sprawdzenie formatu przed umieszczeniem danych w tabeli - IS JSON contraint. Wykonujemy tę komendę w SQL Workshop => SQL Commands:
alter table app_settings
add constraint param_value_json check ( param_value is json );