Correct, David, you got the gist of my comment. Jim Hays gave a great example where I can see object fields excel. If your app requires user defined fields, then an object field is just perfect for that. I’ve had similar situations in the past and used tab-separated text fields first, and then blob fields when that became available. Now object fields would be much much better because you can query on those ‘user defined’ fields, a great improvement over previous implementations.
julio > On Jul 14, 2017, at 11:15 PM, David Adams via 4D_Tech <[email protected]> > wrote: > > On Sat, Jul 15, 2017 at 7:36 AM, Kirk Brooks via 4D_Tech < > [email protected]> wrote: > >> >> Perhaps this is what you are saying and I'm just reading too narrowly (it's >> been that sort of week). >> > > I'm not sure, but I was reading Julio's comment as something akin to > "David, don't do what you were offering as an example recently." > Specifically, storing a zillion copies of what amounts to a record stuffed > into an object and then an object field. Like, if you've *always* got first > name, middle name, last name, put them in fields! Don't put them in an > object that you then put into an object field. You can end up spending most > of your space storing redundant data, namely the keys. > > Now, if you have a bunch of different JSON formats, that's a different > story. Some records might have first name, middle name, last name and > others have interval length, start date, and end date. I don't know, I'm > just making something up. > > The other day I started my experimentation on object field with some code > I'd written. It generated zillions of objects, some in an array and some as > summaries of the array. I thought, hey! I'll store these and then can bring > the results back for different sorts of analysis later. Sure, why not? I > stuffed them into object fields and they were absolutely ginormous. So, I'd > have a record with a field with 96 array elements (24 hours broken into 15 > minute buckets with stats for that interval)...and most of the data is just > the structure of the data...which is the same for every record. It's > obviously a lot more efficient to store the findings in proper tables, > boiled down to a more compact representation, or boiled down to a more > compact representation and stuffed into a blob as UTF8, or exported and > compressed. Whatever. > > So, I was talking about what is called a "stupid example." I believe that > is the correct, contemporary term of art...but it's exactly the sort of > mistake someone else might make, so it's worth thinking about. If you have > an entirely regular structure, why would you store it in an object field? I > have a weird situation where the goal is to store JSON itself, but leave > that out. What is the point of storing your data in an object field? > (Thomas Maul and others also made a point like this on the Forums, unless > I'm mis-paraphrasing.) It doesn't generally make any sense. Here: > > {"total":5} > > If you store this in every single record in a table, what do you gain? > Well, nothing, so far as I can see. instead, put it in a regular field > named "total". Then you don't need to store the string "total" with every > record (the field name itself is the 'key') and the number is stored > directly as a number (more compact, easier to get into arrays, etc.) > > I really have no idea how people are using object fields. 4D has some > demos. I've asked several times in different venues for several months and > have had very little response. So, I suspect that people mostly haven't had > a chance to get to V16 and use them yet. That makes this a good time to > think them through. > > More thoughts and comments wanted! It would be helpful to everyone to hear > real-world stories about how you're finding object fields helpful. For my > money, I'm not likely to use them much. But, like any tool, it's good to > know how they work so that you can fit them to purpose. When there's a good > time to use an object field, I'll be glad to have already thought the > subject through enough to recognize the situation immediately. > > Just to keep things in one place, here's where I can imagine using object > fields: > > * Storing prefs, etc. Don't know if this is "proper" but it sure feels like > a good idea. I often use external JSON files for configuration data anyway. > Very handy. > > * Storing messaging data. If I were to write another distributed, > record-based, task or message queue in 4D, I'd stuff the job/message data > into an object field in a heartbeat. That's a perfect use. > > Where I won't use them, of don't expect to, is for making what amount to > "repeating fields." You know > > Quarter_1_Total > Quarter_2_Total > Quarter_3_Total > Quarter_4_Total > > ...and then the financial years changes and you have to push figures down, > etc. That's just a bad design. I'm also now terribly likely to use them for > things like "aunt Mildred's phone number." I'd have a related table with a > keyword (key) and whatever the value is (value.) Same idea, different > implementation. > > One tricky area that I suspect will come up for people are "type of" > relationships that don't work neatly in the relational model. As an > example, imagine that you've got a bunch of health care facilities. Some > are hospitals, some are clinics: > > [Facility] > Type_ "Hosptial" or "Clinic" > > ...now some fields only make sense for a hospital and some only make sense > for a clinic. Then again, a whole bunch of fields are identical for both. > What's the right design? I don't know. I'm not even sure what this > situation is called as a technical design problem. I do know that classical > ERD syntax has no vocabulary for it. (In contrast, IDEFX and UML both do.) > For my money, this is the one place where the relational model is awkward > enough to bug me. Otherwise, the standard relational model has *massive* > benefits over stuffing a bunch of stuff into a keyword soup. > > Right, done rambling...for now. > ********************************************************************** > 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] > ********************************************************************** -- Julio Carneiro -- Julio Carneiro [email protected] ********************************************************************** 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] **********************************************************************
