Jest wiele innych warunków, o których słyszałem w przypadku systemów nierelacyjnych a relacyjnych. Wolę tę terminologię od sql/no-sql, ponieważ osobiście uważam, że lepiej opisuje różnice, a kilka serwerów „no-sql” ma dodatki do sql, więc w każdym razie… jaki rodzaj wzorca współbieżności lub izolacji transakcji jest wymagane w twoim systemie. Jedną z rzekomych różnic między bazami danych rel i innymi jest „spójne-zawsze”, „spójne-głównie” lub „spójne-ewentualnie”. Bazy danych relacyjnych domyślnie należą do kategorii „w większości zgodnej” i przy odrobinie pracy oraz mnóstwie warunków blokowania i wyścigu;) mogą być „zawsze spójne”, więc każdy zawsze patrzy na najbardziej poprawną reprezentację podana część danych. Większość z tego, co czytałem/słyszałem o bazach danych innych niż relacyjne, to to, że są one głównie „spójne – ostatecznie”. Oznacza to, że może istnieć wiele wystąpień naszych danych, więc użytkownik „A” może zobaczyć, że mamy 92 widżety w ekwipunku, podczas gdy użytkownik „B” może zobaczyć 79 i mogą nie zostać uzgodnione, dopóki ktoś nie odejdzie wyciągać rzeczy z magazynu. Kolejną kwestią jest zmienność danych, jak często trzeba je aktualizować? Konkretne bazy danych innych niż relacyjne, z którymi miałem do czynienia, mają większe obciążenie dla aktualizacji, niektóre z nich muszą ponownie wygenerować cały zestaw danych, aby uwzględnić wszelkie aktualizacje.
Teraz pamiętaj, myślę, że non-rel/nosql są świetnymi narzędziami, jeśli naprawdę pasują do twojego przypadku użycia. Mam kilka projektów, nad którymi się teraz zastanawiam. Ale podczas podejmowania decyzji musisz wziąć pod uwagę wszystkie kompromisy, w przeciwnym razie po prostu zamieni się to w rozwój oparty na wznowieniu.
