MySQL i PostgreSQL jako natywne warianty backendu

Wybór bazy danych jest częścią architektury wdrożenia

W systemie firmowym baza danych nie jest określana wyłącznie przez preferencje programisty. Przedsiębiorstwo może mieć standardy eksploatacyjne, własny zespół administratorów baz, istniejące procedury kopii zapasowych, wymagania dostawcy chmury albo ograniczenia zarządzanego hostingu. Dlatego Sapphire I.C.D.S. obsługuje dwa natywne warianty backendu, MySQL i PostgreSQL, i nie zmusza każdej instalacji do korzystania z jednej z góry wybranej bazy.

Publiczny Roadmap odnotowuje obsługę PostgreSQL jako wydane ulepszenie wraz z pełnym wyborem pomiędzy tymi systemami. Na poziomie architektury oznacza to więcej niż obecność drugiego sterownika: zapytania, schematy modułów i reguły wykonania muszą istnieć dla obu dialektów oraz zachowywać porównywalne działanie.

Jeden kontrakt nad dwoma sterownikami

Wyższe warstwy Sapphire I.C.D.S. nie powinny zależeć bezpośrednio od biblioteki klienckiej konkretnej bazy. Kontroler danych odczytuje wybrany typ backendu z konfiguracji i pobiera odpowiedni natywny sterownik. Moduł wywołujący nadal korzysta ze wspólnego zestawu operacji: pobierania wierszy, zmiany danych, wartości skalarnych, wstawiania grupowego, transakcji i operacji na schemacie.

Takie rozdzielenie utrzymuje wybór technologii w warstwie infrastruktury. Moduł artykułów lub lokalizacji formułuje żądanie dziedzinowe i pracuje z ustrukturyzowanym wynikiem, zamiast decydować o sposobie połączenia z MySQL lub PostgreSQL. Jednocześnie różnice baz nie są ukrywane przez magię; obsługuje je właściwy sterownik i dialekt SQL.

Osobne szablony SQL zamiast warunkowych ciągów

Sapphire I.C.D.S. przechowuje zwykłe zapytania poza kodem modułu i rozdziela je według dialektu. Jedna operacja biznesowa może mieć szablony MySQL i PostgreSQL o tym samym przeznaczeniu i oczekiwanym kształcie wyniku. Przed wykonaniem aktywny sterownik wybiera właściwy wariant, stosuje natywną warstwę parametrów i zwraca dane we wspólnym nośniku tabelarycznym.

To uczciwsza przenośność niż próba uznania całego SQL za uniwersalny. MySQL i PostgreSQL różnią się składnią, typami, identyfikatorami, zwracaniem utworzonych wartości i szczegółami niektórych wyrażeń. Oddzielne, testowalne szablony pokazują te różnice wprost, nie wypełniając modułu biznesowego rozgałęzieniami warunkowymi.

Co pozostaje wspólne dla modułów

• Operacja dziedzinowa. Pobranie listy, zapis rekordu lub zmiana transakcyjna mają jedno przeznaczenie biznesowe.
• Dane wejściowe. Moduł przekazuje ustrukturyzowane parametry przez wspólne środowisko.
• Kształt wyniku. Odbiorca otrzymuje tabelę albo wartość z uzgodnionymi polami.
• Granica transakcji. Operacje, które muszą zakończyć się w całości, korzystają ze wspólnego kontraktu transakcji.
• Wybór backendu. Realizują go konfiguracja i kontroler, a nie warunki rozproszone po modułach.

Czego wybór backendu nie wykonuje automatycznie

Obecność dwóch natywnych wariantów nie oznacza, że działającą bazę produkcyjną można zmienić jednym ustawieniem. Migracja między systemami wymaga przeniesienia schematu i danych, sprawdzenia sekwencji i identyfikatorów, porównania typów oraz kontroli kodowań, indeksów i zachowania transakcyjnego. Potrzebne są kopia zapasowa, plan przestoju lub synchronizacji, próba testowa i kryteria wycofania.

Platforma nie deklaruje też automatycznej replikacji między MySQL i PostgreSQL, wbudowanego przełączania awaryjnego między różnymi bazami ani jednego klastra złożonego z dwóch różnych produktów. Są to zadania infrastrukturalne i wymagają oddzielnego projektu. Natywny wybór backendu oznacza, że Sapphire I.C.D.S. potrafi działać z każdym wariantem w obsługiwanym wdrożeniu, a nie że oba można dowolnie zamieniać bez przygotowania.

Jak wybierać między MySQL i PostgreSQL

Racjonalna decyzja zaczyna się od środowiska klienta. Jeżeli organizacja już eksploatuje MySQL, ma standardowe kopie zapasowe i kompetentny zespół, przejście na inną bazę tylko dla nowego projektu może nie przynieść korzyści. PostgreSQL jest równie naturalny tam, gdzie stanowi standard firmowy, jest dostępny w zarządzanej infrastrukturze i pasuje do monitoringu oraz odtwarzania.

Porównanie powinno obejmować cały cykl życia, nie tylko wydajność jednego zapytania: dostępność specjalistów, aktualizacje, koszt usługi, obserwowalność, politykę rozszerzeń, procedury odtwarzania i wymagania dotyczące danych. Szczególne zapytania konkretnego modułu trzeba mierzyć na reprezentatywnych wolumenach. Wspólny kontrakt nie usuwa różnic pomiędzy optymalizatorami i indeksami.

Równoważność wymaga dyscypliny programistycznej

Każda zmiana schematu lub zapytania musi pojawić się w obu dialektach, jeżeli moduł deklaruje obsługę dwóch backendów. Nie wystarczy sprawdzić, że pliki istnieją. Weryfikacja powinna obejmować czystą instalację, ponowne stosowanie bezpiecznych migracji, testy odczytu i zapisu oraz porównanie wyników. Szczególnej uwagi wymagają miejsca, w których jedna baza inaczej raportuje zmienione wiersze albo zachowuje nośnik wejściowy po pustym wyborze.

Ta dyscyplina zwiększa zakres testów, ale czyni przenośność rzeczywistą. Jeżeli nowy moduł jest zaimplementowany tylko dla jednego backendu, ograniczenie powinno być jawne, a nie ukryte za ogólną deklaracją platformy. Kierownictwo techniczne otrzymuje czytelne kryterium gotowości: ta sama operacja biznesowa powinna dawać równoważny wynik w obu wspieranych wariantach.

Rezultat eksploatacyjny

Dla właściciela firmy dwa natywne backendy oznaczają swobodę dopasowania Sapphire I.C.D.S. do istniejącej infrastruktury i uniknięcie niepotrzebnej zmiany kompetencji. Wspólna warstwa danych chroni moduły biznesowe przed bezpośrednim związaniem ze sterownikiem. Osobne dialekty SQL sprawiają, że różnice są widoczne i testowalne.

Najważniejszą wartością nie jest hasło o obsłudze dwóch baz, lecz granica odpowiedzialności. Organizacja wybiera i eksploatuje backend, kontroler podłącza natywny sterownik, moduł wykonuje operację dziedzinową, a testy potwierdzają równoważność. Model pozostawia otwarty wybór technologii, nie ukrywając rzeczywistego kosztu migracji i utrzymania.