I think just one more thing and that is a caveat. You can NOT access object fields with SQL. You would have to write a sql fn call that would return the data to you.
I for one will not be using object fields until they become available through sql. As much as I like the idea, I move to much data between systems using SQL. Regards Chuck On Thu, Jul 13, 2017 at 11:21 PM, David Adams via 4D_Tech < 4d_tech@lists.4d.com> wrote: > 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:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** -- ----------------------------------------------------------------------------------------- Chuck Miller Voice: (617) 739-0306 Fax: (617) 232-1064 Informed Solutions, Inc. Brookline, MA 02446 USA Registered 4D Developer Providers of 4D, Sybase & SQL Sever connectivity http://www.informed-solutions.com ----------------------------------------------------------------------------------------- This message and any attached documents contain information which may be confidential, subject to privilege or exempt from disclosure under applicable law. These materials are intended only for the use of the intended recipient. If you are not the intended recipient of this transmission, you are hereby notified that any distribution, disclosure, printing, copying, storage, modification or the taking of any action in reliance upon this transmission is strictly prohibited. Delivery of this message to any person other than the intended recipient shall not compromise or waive such confidentiality, privilege or exemption from disclosure as to this communication. ********************************************************************** 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:4d_tech-unsubscr...@lists.4d.com **********************************************************************
