I was making some related comments on the forums in France today and Rob Laveaux, a hero of the 4D world, made a great technical post:
Hi David, Please elaborate what makes you conclude this? You seem to imply that objects fields are stored in JSON format, but I'm sorry ... that is not true. Take a hex-editor to examine your datafile and you will see they are stored in a binary format. I just want to set this straight, before it is taken as a fact by others. Of course, if you store large objects, they occupy disk space. Just like large text, picture or blob fields. Compression of data is possible, but it comes at a cost: the cost of decompression and recompression. This takes CPU time, which is more costly than the cost of disk space. But I agree, it would be nice to have data compression as an option. Greetings, Rob I wanted to repost it here for the sake of the archives because, according to Rob, I'm starting an erroneous superstition. I'm still in the dark about the real-world story and trade-offs in 4D'S object fields (I tired them for the first time yesterday), and hopefully we'll get some more details out of the folks in France. For now, it looks like, based on what Rob says, thing aren't as dire as I feared - but I don't have an easy way to quantify that yet. Not keen to get out a hex editor and start experimenting/counting when France could just tell us. ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
