> On Mon, Jul 17, 2017 at 6:50 AM, Julio Carneiro via 4D_Tech < 4d_tech@lists.4d.com> wrote: > 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. Yes, I can easily see that object fields are the best current, native way to handle user defined fields in 4D. I'm getting the impression that is pretty much their entire purpose, or close to it. I can see how that is value to some OEMs (I'd expect DataWorks to use it as they've always found UDFs a competitive advantage for them.) But for me? I've never had that requirement and don't expect to. The uses I have for storing JSON sound like they're just not on the list of problems that object fields in 4D are *intended* to solve. So, it's not a great match. I had a quick look at what PostgreSQL offers and their 9.4 release (2.5+ years ago) has a couple of native options. They've got a 'json' field type and a 'jsonb' field type. The first is for straight validation of JSON as it is, but with engine-level validation. So, basically a text field that can store any valid JSON that kicks an error if you put something else in. The jsonb type restructures the JSON into a custom binary format for index optimization. Not to save space, but to make searches possible, flexible, and fast. This is integrated with some ongoing work they've been going with full-text searching, a la Solr. (The GIN index, specifically.) So, super optimized to complete for a lot of the spaces that MongoDB plays in. PostgreSQL supports some syntactic conventions to allow for indexed searches *within* nested JSON, very nice. Out in that wider world, saving raw JSON for log analysis, messaging, API analysis, pre-calculations, etc. is all entirely ordinary. In an all 4D world, apparently not so much. In an all 4D world, those uses seem to be "not recommended." In a world where 4D is part of a larger pipeline, some of the other tools sound like a more natural fit for JSON storage. It took me about 45 minutes to get a really good sense of the options in PostgreSQL along with costs, limitations, trade-offs, and competitive comparisons. The information was available at whatever level of technical detail I could have been interested in...and then some. It's pretty fun to read about this stuff. ********************************************************************** 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 **********************************************************************
