2013-09-22 11 views
6

Mam klienta Angular JSON JSON współpracującego ze stosem JAVA/MySQL. Ponieważ MySQL to RDBMS, wszystkie moje dane są znormalizowane (pierwsze trzy formy oczywiście).Normalizacja kontra DeNormalizacja podczas używania klienta JSON ze stosem JAVA/RDBMS

Moje pytanie można zilustrować następującym przykładem.

Mam obiekt Example i obiekt User zwrócony przez serwer.

Example - [{ 
userId:1, 
... 
... 
.. 
}, 
{ 
userId:2, 
...}, 
{ 
userId:3, 
...}]; 

User - [ 
{ 
userId - 1, 
firstName - "John", 
lastName - "Doe", 
.. 
}, 
{ 
userId - 2, 
firstName - "Jane", 
lastName - "Doe", 
.. 
}, {...}... 
] 

Gdy spojrzeć na przykładzie odbioru za pomocą kątowego „example_entry w przykładzie” i wyświetlania elementów Przykład kolekcję, tylko mają userId łatwo dostępne. Ale jeśli chcę wyświetlić firstName i lastName, nie mogę tego zrobić tak, jak w innej kolekcji "User". Muszę napisać pomocnika Angular kontrolera/metody usługi, aby uzyskać firstName, lastName z kolekcji User i powiązać go z przykładowymi obiektami kolekcji.

Aby uniknąć tego problemu, mogę De-Normalizuje się Ojbects Java i wysłać gotowe do użycia JSON tak ..

Example - [{ 
userId:1, 
firstName - "John", 
lastName - "Doe", 
... 
... 
.. 
}, 
{ 
userId - 2, 
firstName - "Jane", 
lastName - "Doe", 
...}, 
{ 
userId:3, 
...}]; 

Ale jest to straszne dobry/zły /? Ponieważ teraz moje obiekty domeny Java mają firstName, LastName duplikowane w obiekcie Example, a także Object użytkownika. Czy wiesz, która trasa jest lepsza?

De-Normalize and have ready to use JSON 
Keep Data Normalized to avoid duplication and write converter methods on the Client as needed 

Odpowiedz

2

Oto moje zdanie na ten temat. Jeśli chodzi o wyświetlanie danych \ listing, nie martwię się o model domeny \ classes. Dla mnie zwrócone dane powinny w jak największym stopniu odpowiadać wymaganiom wyświetlania interfejsu użytkownika. Tutaj celem jest pokazanie danych użytkownikowi, a niewiele takich decyzji jest podejmowanych.

Ale jeśli dane muszą zostać zmienione \ zaktualizowane należy bardziej uważać na to, co jest wysyłane, które jednostki biorą udział w aktualizacji. Utrzymywanie spójności danych staje się priorytetem, a de-normalizacja może nie być odpowiednia w takich przypadkach.

+0

Czy to oznacza, że ​​powinienem opuścić Backend Java Classes tak jak jest i napisać metody pomocnicze, aby przekonwertować JSON po stronie serwera do znormalizowanego JSON? Dzięki. – user6123723

+0

Jeśli jest to lista danych, utwórz widok z wymaganymi polami w DB i po prostu przetestuj go za pomocą kodu aplikacji, bez potrzeby transformacji. W przypadku aktualizacji jednostki \ aktualizacja danych należy wysłać poprawną encję danych zamiast dokonywać denormalizacji na bakend. – Chandermani

+0

Ale czy to nie sprawiłoby, że pamięć masowa byłaby niewydajna w przypadku Denormalizacji? Teraz, jeśli nazwa fName lub lName ulegnie zmianie, musi zostać zaktualizowana w więcej niż jednym miejscu. Również miejsce do przechowywania używane teraz jest więcej. Czy to nie są problemy? – user6123723

4

Należy denormalizować dane po wysłaniu ich do warstwy interfejsu użytkownika.

Jeśli dane znajdują się w bazie danych, jest to doskonałe miejsce na znormalizowane dane. Użyj widoku, który usuwa tę normalizację i wysyła zapytanie do widoku. Widok pozwala łączyć ze sobą tabele, aby uzyskać zdenormalizowane dane z bazy danych.

W warstwie UI chcesz mieć przejrzysty, prosty wyświetlacz - wtedy kąt jest najlepszy. O ile nie wyświetlasz bardzo dużych ilości danych na ekranie lub nie przesyłasz ogromnych ilości przez sieć, będziesz o wiele lepszy, wysyłając zdenormalizowane dane prosto z bazy danych. DB jest świetny w wykonywaniu sprzężeń i innych funkcji zapytań danych - jest do tego zbudowany. JavaScript może zrobić, ale to nie jest najlepsze z tego.

Powiązane problemy