Hi Bob, i will tell a little story that aligns perfectly with what you told:
I have a huge database system for managing car spare parts. each part can be of a specific type, thus having specific descriptive criteria each part can be linked to any number of vehicles, sometimes with a specific set of limiting criteria (age range, chassis numbers, etc) articles are categorized using what we call a generic article (you might call it a template) and for this article type there is a definition wich criteria need to be filled and wich ones are optional, also if criteria have a defined enumeration list, it can be limited for that specific use. we have long ago decided against using any kind of object for setting these criteria, as we loose flexibility: Finding articles based on generic article and criterium is quite fast in standard tables, but when it comes to mass application of criteria or mass modifications a separate table is much more flexible, also on im- and export, data aggregation, reporting, etc. etc.. The data structure is quite complex, granted, but I have yet to find a compelling reason to use anything else, as there is nothing I cannot do with a separate table. And that is my main argument: IMHO it only makes sense to switch to another tool if there is a distinct benefit, and that is something I do not see yet, on the contrary, there are a lot of things i cannot do easily when using object fields. So for now, until a compelling reason comes along, I use objects only as a kind of „attic“ for the record, keeping complex data I only need from time to time (audit trail, source file references, record history, etc. etc.) and that never will be used for any business logic. OTOH I love c_objects variables in the language and make heavy use of these, they allow for a much cleaner approach to development (from passing parameters, to replacing process variables, storing form object settings, etc. etc.). Hope this helped, available for further questions, also by PM. Cheers Alex > Am 13.09.2017 um 16:28 schrieb bob.miller--- via 4D_Tech > <[email protected]>: > > Along the lines of, "what is an appropriate use of an object field", I've > been considering this: > > We are a manufacturing company with lots of tools and lots of products. > Each tool has various attributes, but each tool type has a different set > of characteristics. > > Silly example that I hope everyone can follow: if the tool type is > "screwdriver" then the attributes might be: > > Tip Type (blade, Phillips, Torx, etc.) > Tip Size (#1 or #2) > Shank length (in mm) > Handle diameter (in mm) > > > ...If the tool type, however, is "hammer" then the attributes might be: > > Head type (claw, peen, sledge, etc.) > Claw shape > Head weight > Shank material > Shank length > Grip Type > ...and many more > > > Common to all tools, regardless of tool type are attributes such as: > > Tool ID > Tool Type - which determines the format and contents of the object field > that contains the attributes > Storage Location > Purchase Date > Condition (good, fair, poor, unusable) > Status (ready to use, in use, lost) > > > 90% of the time users want to enter a Tool ID to retrieve the Storage > Location, Condition, and Status. 10% of the time they know the tool type > but don't know the tool ID and want to query for a tool to do the job, > using one or several attributes. I've been thinking that because there > are so many tool types and so many attribute "collections", an object > field might be a good place to store the attribute data in name-value > pairs. This way I don't have to have a table with every single attribute > name, which would be a problem because I don't know them in advance (users > want to be able to specify the attributes themselves, along with the > attribute value of course) and many tools do not share many attributes, so > a big mostly-empty record would result if I used fields. > > The object field on a record with Tool Type = "screwdriver" would contain > attributes for a screwdriver, while the object field on a record with a > different Tool Type would contain a different set of attributes. A table > for "Tool Type" would have one record for each tool type and could also > use an object field to contain the attribute names, since this would be > more handy than having multiple records for each tool type, one for each > attribute name. The normalized, relational model isn't really needed > here, though of course it could be used. > > An object field seems ideal for this kind of application, and 'Query by > Attribute' certainly makes it possible. > > There are always LOTS of ways to solve a problem, but do you agree that an > object field is a good way to solve this one? If it is a mediocre way to > solve it, I'd like to hear your comments! > > > Bob Miller > Chomerics, a division of Parker Hannifin Corporation > > > > ********************************************************************** > 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] > ********************************************************************** ********************************************************************** 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] **********************************************************************
