🚀 go-pugleaf

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.

>> 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.

> 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. 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. 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:

"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ę.

pozdrawiam,
geos