@alosha: To teraz popatrze - JEE to są szprychy w tym kole. Jedno przestanie działać, to rower jakoś pojedzie. Może nie działać frontend, może nie działać, backend, może nie działać baza danych, ale coś będzie działać. A teraz wyobraź sobie, że wszystko jest złączone w jedno miejsce - jesteś kołem z jedną szprychą, co się stanie jak ona zawiedzie?
Złożoność problemu jest większa i nie obrazuje tego mój przykład opisowy, ale
@Anaris: każda z tych technologii ma udział w tworzeniu rozdętych aplikacji, kiedy używa się ich razem. Przykład z życia wzięty: dostajemy pliki xml i zapisujemy je na bazie danych jako bloby czy xmlcośtam. Niby każdy wie, że to głupota, ale widziałem wiele systemów "enterprise", które tak robią dla lepszej diagnostyki, bo tak wygodniej, itp.
A potem się pisze query które parsują xmla na żywca...
@GotoFinal: Pracowałem w 3 firmach. W każdej trzymali xmle w tabelkach. Zaczynam sądzić, że to standard i good practice ;)
PS w 2 z nich część kodu źródłowego jest pisana przez analityków w plikach .xlsx w nieudokumentowanym, własnościowym pseudojęzyku programowania , parsowana i przetwarzana/interpetowane (w różne sposoby) na kod javowy :)
@tell_me_more: @alosha: też mnie XML #!$%@? ale z drugiej strony lepszy głupi standard niż żaden ;-) JSON jest fajny i go lubię bo to bardzo czytelny format i przyjemnie się go parsuje, niestety nie zawsze stanowi alternatywę- średnio się nadaje jako zastępnik XSD za to świetnie się nadaje do przesyłania surowych danych, typów prostych, płaskich obiektów i tablic.
@Anaris: parsowałbym przy wczytywaniu do struktury mapowanej normalnie na kolumny w bazie danych. cały sens relacyjnej bazy danych jest taki, żeby nie trzeba było sobie wydobywać z pól wartości za każdym razem.
Nie robiłbym pól "additional_parameters" które trzymają dane, których się nie opłaca dorzucać do schematu bazy danych, bo potem niewątpliwie ktoś zechce po nich wyszukiwać albo sortować.
@tell_me_more: są też inne pola do zastosowania XMLa poza "additional parameters". Jeden z przykładów: tabela z danymi konfiguracyjnymi - nazwa jako tekst i wartość jako XML, który sobie ładnie deserializujesz do obiektu (chociażby w Javie - XStream pomaga). Milion razy wygodniejsze niż tworzenie oddzielnego rekordu dla każdej wartości konfiguracyjnej: "adresDoBramkiSMS", "loginDoBramkiSMS", "hasłoDoBramkiSMS". itd... Sortować nikt tego nie będzie, parsować na bazie też nie.
A teraz wyobraź sobie, że wszystko jest złączone w jedno miejsce - jesteś kołem z jedną szprychą, co się stanie jak ona zawiedzie?
Złożoność problemu jest większa i nie obrazuje tego mój przykład opisowy, ale
A potem się pisze query które parsują xmla na żywca...
PS: co to Oacle? ( ͡° ͜ʖ ͡°)
Ale webdev to i tak rak.
@tell_me_more: A wiesz Pan, że musiałem kiedyś to robić? Logi były w XMLu...
PS w 2 z nich część kodu źródłowego jest pisana przez analityków w plikach .xlsx w nieudokumentowanym, własnościowym pseudojęzyku programowania , parsowana i przetwarzana/interpetowane (w różne sposoby) na kod javowy :)
@alosha: no ja też. to całkiem częste :)
@tell_me_more: a jak ty byś to zrobił?
JSON jest fajny i go lubię bo to bardzo czytelny format i przyjemnie się go parsuje, niestety nie zawsze stanowi alternatywę- średnio się nadaje jako zastępnik XSD za to świetnie się nadaje do przesyłania surowych danych, typów prostych, płaskich obiektów i tablic.
Nie robiłbym pól "additional_parameters" które trzymają dane, których się nie opłaca dorzucać do schematu bazy danych, bo potem niewątpliwie ktoś zechce po nich wyszukiwać albo sortować.
Jeden z przykładów:
tabela z danymi konfiguracyjnymi - nazwa jako tekst i wartość jako XML, który sobie ładnie deserializujesz do obiektu (chociażby w Javie - XStream pomaga). Milion razy wygodniejsze niż tworzenie oddzielnego rekordu dla każdej wartości konfiguracyjnej: "adresDoBramkiSMS", "loginDoBramkiSMS", "hasłoDoBramkiSMS". itd...
Sortować nikt tego nie będzie, parsować na bazie też nie.