Having just started looking at object fields and learned a few things, I have a few thoughts. For background, I've been using 4D's C_OBJECT and ARRAY OBJECT for some time, and now I'm looking at object fields. I think that I've gotten a grip on some of the details through experimentation, help from people on this list, and help from people on the 4D Forums in France. If I say something that makes no sense or is wrong, I'd would really like to hear about it. The more accurate my picture of how things work, the more intelligently I can make choices. For the record, some of my requirements are probably atypical, but knowing about the underlying performance and storage behaviors in 4D is useful knowledge for most people.
For background (corrections and additions invited), I think this is more-or-less the story: * 4D stores all textual data as UTF16. * 4D's native JSON features aren't a complete JSON implementation. The commands only support a limited/specific set of JSON styles/formats/patterns. These patterns are valid JSON, but they're not particularly space optimized. This isn't a bug, it's just how it is. * Object fields are basically text fields with extra constraints *and* extra features. So, the storage requirements for the same data are roughly (or exactly?) the same for the same JSON. * The extra constraint on object fields is that they can only store JSON objects that are parsable by 4D. For example, you can't store an ARRAY OBJECT without injecting it into a C_OBJECT wrapper first. * The extra feature on object fields is the index. There's a special kind of index available (the details are secret) that makes lookups by key fast and somewhat flexible. * Text and object fields may be different internally, or they may be the same...it doesn't matter to us as 4D developers - we just care about how they work and what we can do with them. * Unless you need the object field index & search, there is exactly *no reason* to use an object field instead of a text field. * Text fields give you a keyword search option which object fields lack. * If you're storing something like some key names and numbers in an object field, the storage requirements are going to be *much* higher than storing the same data in real numeric fields for two reasons: -- The key name is repeated in each object -- The value is stored as text - which makes numerics take 4x times as much space. * The previous point is _only_ a concern to people (like me) that are trying to store and process a lot of data. Also (in my case), I'm storing fully prepared JSON for export to/interaction with other systems. So, using tables as a JSON repository, not because there is any reason to search the JSON. The JSON is an output product. In such a case, it makes sense to push the data out to something where you can use a smaller character set (Latin1, UTF8), if you can get away with it. If you're storing Chinese surnames, you need UTF16 (I think), if you're storing numbers, you may only need Latin1. * If you're dealing with some sane number of records, space issues are likely not a big deal for you and it's absolutely not worth worrying about. * Standard fields are directly searchable, easy to display, easy to sort by, simple to export, etc. If you're burying data inside of an object instead, you need a good reason to justify the costs of making the data harder to access. I'd love to hear what people have found as good reasons in their own work. Does that all sound about right? Am I missing reasons why I would want to use object fields. vs. text fields? Any other technical details that people have learned or figured out? Thanks. ********************************************************************** 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] **********************************************************************
