🚀 go-pugleaf

W dniu 2018-02-13 o 15:10, geos pisze:
> On 13.02.2018 14:39, wloochacz wrote:
>> W dniu 2018-02-12 o 21:27, geos pisze:
>>> On 12.02.2018 19:12, wloochacz wrote:
>>>> W dniu 2018-02-10 o 18:59, geos pisze:
>>>>>
>>>>>> I tu właśnie, nawiązując do sąsiedniej Twojej odpowiedzi, PostgreSQL
>>>>>> z typem, podkreślam: typem danych json, może być doskonałym
>>>>>> środowiskiem do realizacji takiego hybrydowego rozwiązania.
>>>>>
>>>>> a ma on jakąś przewagę nad xml-em (też obsługiwanym w bazie
>>>>> relacyjnej)?
>>>> Oczywiście, jest prostszy i bardziej zwarty, a co za tym idzie - te 
>>>> same
>>>> informacje zajmują mniej miejsca.
>>>> Oczywiście to nie tak, że JSON to lepszy XML.
>>>> Nic a nic.
>>>>
>>> ech, chyba tak nie do końca bo:
>> Oczywiście, że do końca.
>>
>>> Binary XML storage. This is the default storage for Oracle XML
>>> Database. XML Typedata is stored in a post-parsed binary format
>>> specifically designed for XML data. Binary XML is compact,
>>> post-parsed, and XML schema-aware XML.
>>>
>>> http://www.oracle.com/technetwork/database/database-technologies/xmldb/overview/xmldb-store-12cr1-2043451.pdf 
>>>
>>
>>
>> Nie zauważyłeś jak pisałem o JSON/BSON?
>> BSON to odpowiednik binary XML dla JSON.
> 
> nie, nie zauważyłem. odniosłem się do postu. zacytowałem go w całości i 
> na niego odpowiedziałem. był tam json. nie śledziłem dokładnie całego 
> wątku a być może nie pamiętałem co przeczytałem w postach innych 
> odnosząc się do konkretnego.
To nie czytaj po łebkach!
Odpowiedziałem tylko i wyłącznie na ten kawałek:
"a ma on (tj. JSON) jakąś przewagę nad xml-em (też obsługiwanym w bazie 
relacyjnej)?"

Ale wcześniej nie pisałem o samym JSON - nic a nic.

A może Ty jakiegoś krzywego czytnika używasz (i nie widzisz poprawnie 
cytatów), co? :)

>>> oczywiście potrafi też tekstem. podczas gdy w postgresql:
>>>
>>> So it appears that, for now at least, json is the same as a text
>>> datatype but with JSON validation. The text datatype's maximum size is
>>> 1GB.
>>>
>>> https://stackoverflow.com/questions/12632871/size-limit-of-json-data-type-in-postgresql 
>>>
>>
>> A co ja napisałem, wcześniej?
>> Że z kozy się nie da konia zrobić, bo żadna baza relacyjna nie będzie
>> fajna i miła jak baza NoSQL w zakresie przetwarzania danych 
>> nierelacyjnych.
>> Zatem nie napisałeś mi nic nowego...
> 
> w ogóle nie pisałem o nosql ani nie miałem zamiaru pisać o nosql. 
> napisałem o sposobie składowania. jeden cytat wziąłem z wątku 
> poświęconym postgresowi.
Nie.
To Ty wyleciałeś z Postgresem do mnie, jako przykład przetwarzania w 
bazie relacyjnej.
I, OK - tylko wcześniej dokładnie do czegoś takiego się odniosłem. A 
konkretnie - to nie jest fajny pomysł, zwłaszcza jeśli są to dane 
operacyjne o sporej dynamice zmian/odczytów.

>> To znaczy, że zęby bolą jak się to czyta ;-)
> 
> piszesz w poście o json, odpowiadam na tego posta, poźniej mi sugerujesz 
> bson. ok. 
NIE!
Znowu po łebkach... I na dodatek wyciąłeś całe clue mojej wypowiedzi...

> odnosząc się do typu json, konkretnie do "zajętości" cytuję 
> konkretną dokumentację/post z internetu dotyczącą metody składowania 
> (ciągle odnosząc się do cytowanego postu) dla konkretnego typu. 
W jednej konkretnej implementacji (a nie, przepraszam - w dwóch 
implementacjach. PostgreSQL i Oracle) danej bazy relacyjnej.
I co z tego?

> okazuje 
> się, że źle odpowiedziałem bo chodziło o  nosql. masz wątpliwości co do 
> składowania typu tekstowego, ale cytat z dokumentacji postgresa:
Ja nie mam żadnych wątpliwości, po prostu wiem jak to działa.
I nie sugerowałem takiego rozwiązania dla bazy relacyjnej.

> "The storage requirement for a short string (up to 126 bytes) is 1 byte 
> plus the actual string, which includes the space padding in the case of 
> character. Longer strings have 4 bytes of overhead instead of 1. Long 
> strings are compressed by the system automatically, so the physical 
> requirement on disk might be less."
> 
> odnosząc się pośrednio do pierwotnego problemu i mając na uwadze, że 
> jeśli json to jest spora szansa, że w tych 126 bajtach komunikat z 
> czujnika z pięcioma pomiarami się zmieści, np:
> 
> {"CZ":"kuchnia1","T":"-11.1","C":"1101","W":"98","X":"1546","Y":"abc"}
> 
> więc miałem podstawy aby poddać w wątpliwość to co poddałem. ale znowu 
> pewnie czegoś nie zrozumiałem. więc tak sobie myślę, że chyba się nie 
> rozumiemy na poziomie fundamentalnym. ze swojej strony przepraszam za 
> złą interpretację.
Fakt, nie kumam co tu piszesz.
Jeszcze raz - mi się wydaje, że dla takich a nie innych wymagań baza 
NoSQL jest dobrym wyborem.
Podkreślam - baza NoSQL, a nie JSON w bazie relacyjnej.

-- 
wloochacz