Porównanie typów JSON i User-Defined w PostgreSQL 9.3

Question

Zastanawiam się, dlaczego tyle jest zamieszania w obsłudze JSON w Postgresie 9.3. Jakie są zalety JSON nad typami zdefiniowanymi przez użytkownika (UDT)? Jakie są pułapki w używaniu UDT? Czy dostęp do tabel z UDT jest nieefektywny? Czy atrybut ALTER TYP ADD jest wolny? W jaki sposób UDT są fizycznie przechowywane przez PostgreSQL?

Proszę wyjaśnić i podać linki do dodatkowych informacji.

Answer 1

Mniej poważnie to marketing trochę :). Bardziej poważnie - wewnętrzne wsparcie JSON jest ostatnim etapem kilku lat prac nad tym tematem. Nie ma dużej różnicy między typami wewnętrznymi a UDT, a wiele typów wewnętrznych (i funkcjonalności) rozpoczyna się jako UDT lub UDF. Przejście do wyższego szczebla jest względnie trudnym procesem, a koncepcja (i API) praktycznie nie jest testowana i omawiana. Wewnętrzna implementacja gwarantuje znacznie wyższą jakość i wyższą stabilność (mniej błędów, bardziej stabilny interfejs API) i wsparcie. Społeczność mówi: "jest to dla nas interesująca funkcja, którą chcielibyśmy ulepszyć i wspierać". Nie ma innych różnic - (w wydajności lub formacie przechowywania).

Answer 2

• Myślę, że JSON jest znacznie bardziej elastyczny niż typy zdefiniowane przez użytkownika, możesz dodać dowolne opcjonalne atrybuty, możesz je zagnieździć, możesz umieścić je w listach;
• JSON jest formatem bardzo czytelnym;
• JSON to standardowa notacja obiektowa w wielu językach (Javascript, Python), dzięki czemu można odczytać dane z tabeli i używać ich;
• Nie musisz tworzyć nowego typu w dowolnym momencie, kiedy chcesz przetworzyć dane, możesz utworzyć JSON, przetworzyć go, a potem o nim zapomnieć;

Answer 3

Jak Roman Pekar wspomniano w jednym z poprzednich odpowiedzi, JSON wsparcie oferują znacznie większą elastyczność i oferuje możliwość trochę naśladować NoSQL zachowanie na relacyjnej jeden.

Ponadto ułatwia aplikacjom Client-Server zapisywanie wartości JSON wysyłanych z klienta bezpośrednio z bazy danych.

Można użyć 30% pól dla klienta aplikacji, 30% dla innego itd., Bez konieczności definiowania wielu tabel lub tabel z dużym zestawem kolumn. W ten sposób można przechowywać w jednym miejscu duże porcje heterogenicznej informacji .

Wreszcie, JSON jest standardem i jest obsługiwany przez wiele dużych języków programowania.

(Obecnie, korzystając z funkcji w naszym projekcie (i używam go, ponieważ w wersji beta), a ponadto było to głównym powodem wybraliśmy PostgreSQL dla naszej aplikacji, jak potrzebowaliśmy duży dB głównie oddzielona informacje Próbowaliśmy używać baz danych NoSQL, ale potrzebowaliśmy zbyt wielu tabel do przechowywania informacji i było to kosztowne przy "sprzężeniach", z drugiej strony trudno byłoby radzić sobie tylko z relacyjnym DB, więc zamiast iść pół-relacyjne pół-nierelacyjne wybraliśmy wsparcia Postgres „s JSON)

Answer 4

Niektóre rzeczy o typach zdefiniowanych przez użytkownika.

1. Są w formacie ustalonym (JSON to bezpodstawnie)
2. Możesz wysnuć z nich wnioski.
3. Masz większą elastyczność w rozwiązywaniu problemów z indeksowaniem.
4. Typ złożony (jedna forma UDT) może mieć atrybut JSON.

Typy zdefiniowane przez użytkownika pozwalają na znacznie bardziej niezawodne rozszerzanie SQL w porównaniu z tymi typami niż JSON, ale JSON zapewnia o wiele większą elastyczność. Ponadto typy zagnieżdżone są bardziej elastyczne pod względem wsparcia, gdy są wykonywane jako typy złożone niż obiekty JSON w 9.3 (chociaż to może się w pewnym momencie zmienić). Nie można przekonwertować, w 9.3, obiektu JSON na typ złożony, jeśli obiekt JSON jest w ogóle zagnieżdżony.