Jestem stosunkowo świeżo po studiach, więc większość mojej znajomości relacyjnych baz danych pochodzi z mojego kursu baz danych, gdzie wszystko, co nie jest w BCNF lub 3NF, jest parodią. Z pewnością jest to jeden koniec ekstremum, ale mój zespół w pracy naprawdę wydaje się, że doprowadza go do kompletnego przeciwnego końca.
W naszych schematach db mikrousług, jednostki rzadko mają więcej niż jedną tabelę. Wszystko, co zwykle normalizujesz w innej tabeli, jest przechowywane w kolumnie Json. Jeśli później okaże się, że należy zapytać o jedną z właściwości w tym pliku Json, dodawana jest nowa kolumna, a dane są przechowywane w obu miejscach (tak, w dwóch różnych kolumnach w tej samej tabeli).
W wielu przypadkach te kolumny Json zdecydowanie mają przewagę. Jeśli nigdy nie musisz pytać o te dane i jeśli nigdy nie musisz wprowadzać jednostronnych zmian do tych danych (czego oczywiście nie możesz przewidzieć), nie jest to zły pomysł. Ponadto wiele naszych usług albo nie widzi serwera, albo jest hostowanych na maszynach z nieprzyzwoitą ilością miejsca na dysku na to, czego potrzebowały, więc duplikacja danych nie jest ogromnym problemem. (Chociaż coś, co ogólnie chciałbym uniknąć z filozofii)
Obecnie tworzymy usługę, która dopasowuje reguły w oparciu o zestaw warunków, które posiadają, a następnie wykonuje zestaw działań związanych z tymi regułami, gdy reguły są prawdziwe (np. Wszystkie warunki są spełnione). Mój zespół podrzędny, który od razu buduje tę usługę, uważa, że normalizacja działań i warunków z dala od reguł w schemacie przynosi znaczne korzyści. Oczywiście tabela ta utrzymuje relacje klucza obcego z identyfikatorem reguły. Z naszej perspektywy możemy uniknąć powielania danych w warunkach, co pozwala nam zapewnić, że są one oceniane tylko raz i łatwo jest znaleźć warunki i reguły, których potrzebujemy, gdy są potrzebne, bez konieczności wyciągania każdej reguły i wyszukiwania w pamięci.
Rozmawiając dziś z jednym z naszych głównych inżynierów, próbował odepchnąć mnie daleko od tego schematu. Próba argumentowania pod każdym względem, że tak naprawdę go nie potrzebujemy, spowoduje w przyszłości problemy z wydajnością, odwołując się do starego monolitu, który posiadamy, który jest parodią projektową. Nazywał to, co robimy, „starym sposobem”, a płaskie stoły z Jsonem „nowym sposobem”. Twierdził, że w miejscach, w których chcę atomowości, nie potrzebujemy jej i że zamiast zapytań powinniśmy robić więcej rzeczy w pamięci. Jest to zasada projektowania, której przestrzega obecnie wiele naszych usług. Nie spodziewamy się, że ilość naszych danych znacznie wzrośnie, co powinno przyspieszyć nasze zapytania. To, czego oczekujemy, to dużo czasu poświęconego na ocenę reguł i wykonywanie działań.
Rozumiem, że nierelacyjne bazy danych stały się bardziej popularne w ostatnich latach, ale nawet kiedy aktywnie szukam informacji na temat wpływu relacji klucza obcego na wydajność, nie widzę wielu informacji przemawiających za jego argumentem. Przypuszczam, że mogą wprowadzać duże transakcje, które mogą powodować problemy, ale wydaje się, że jest to problem niezależny od samego klucza obcego.
Czy to moja naiwność? Czy jest to coś, czego naprawdę brakuje mi i mojej ekipie? Wyraźnie nie podałem szczegółowych informacji na temat naszego problemu, ponieważ niekoniecznie szukam rozwiązania tego problemu. Biorąc pod uwagę, że jest to powszechny trend w naszym większym zespole, jestem naprawdę ciekawy, czy coś z tym wiąże.