On Sat, Jul 15, 2017 at 7:36 AM, Kirk Brooks via 4D_Tech <
4d_tech@lists.4d.com> 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:4d_tech-unsubscr...@lists.4d.com
**********************************************************************
