function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
brooksbrooks 

tables to fields . . .

Hi. I'm taking some tables in a .doc and putting them in a custom object.

It seems to me that the best way to do that is use a logical naming convention for each field that represents a cell.

Here's an example:

The table in my .doc is called "Doors." And the column headers are "Name," "Area," "Type," and "Location."

So, I'm calling the first set of fields, which correspond to the first row in the table, the following:

"Door Name," "Door Area," "Door Type," "Door Location"

And the second set of fields, which correspond to the second row in the table . . .

"Door Name 2," "Door Area 2," "Door Type 2," "Door Location 2"

. . . and so on for however many rows are in the table.

Is there a more elegant way to do this? Obviously, each field has to have a unique name or you would have no idea what you're doing when you run a report. But I thought I'd run it by this thundering herd.

Thanks for any feedback.






RickyGRickyG
brooks -

The method is not appropriate and does not follow the basic guidelines for database design.

A table is a collection of records with the same structure - as is an object on the Force.com platform.  Each row of the table in your document has the same structure, so they should be records in an object.

Typically, naming convention calls for the object to be named Door (or Doors, depending on preference), and the fields to be named Name, Area, Type, etc. - you will always be referencing the fields in the context of the table, so no sense repeating the identifier.

If you could convert the table in the document to an Excel spreadsheet, you could use the data import tool or Data Loader to load the values into a Force.com object.

Hope this helps.
brooksbrooks
Rick,

Thanks for responding.

Yes, I agree that a single table should be translated into an object.

In this case, I have multiple tables (in the .doc) that are part of a larger set of data that is in the object. But good database design still dictates that I break those tables out into separate objects, I suppose.

I've not run reports across so many objects at once - call it 15 - am I going to experience any limitations?

Thanks,
Brooks
RickyGRickyG
brooks -

Will you run into reporting limitations?  Probably.  The absolute limit for number of objects in a custom report type is 20, but are you actually going to have all 15 object joined in relationships? 

If the tables are part of a larger set of data, create an object to represent that larger set of data.  This is a much more straightforward way to handle what I understand about your situation.
brooksbrooks
Right, the best design is a standard object to a master object to several child objects . . . as you're saying. And I'll have to see if I can report on the child objects adequately.

Thanks for the feedback.
RickyGRickyG
Actually, no.  The best design is a single object, which would be either a custom object or a standard object, and which would hold all the 'sub-objects', or tables in the document.

Just wanted to make sure that was clear.
brooksbrooks
My design needs to be:

Standard Object -> Master Object -> Child Objects.

We've been talking about the Master to Child relationships. I didn't mention the Standard object that was part of this, which is partly where my concern about reporting comes from.
brooksbrooks
I just want to add to this thread that I wanted to somehow put more than one table in a single object rather than breaking them out into their own objects is because of the reporting limitations across objects.

Meaning, there is no "grandfather" reporting that incorporates the data in the child of a child.

Nor can you report on "spiders" or multiple child objects off a primary object.

Obviously, it isn't intuitive to have limits on reporting on what is one set of data even though subsets of that data reside in different objects.

That's no excuse for thinking of implementing an ugly hack, but . . .
RickyGRickyG
"Meaning, there is no "grandfather" reporting that incorporates the data in the child of a child." - yes there is - custom report types.

You should explore this and other options before you go denormalizing your object structure.  You may end up having to do so, but this type of design is a workaround, at best, and as such frequently causes other problems down the road.
brooksbrooks
Agreed, I've already broken the tables into child objects.

Yes, now I know about adding fields from a grandfather object via a new Report Type, so that I can report on a parent-child object and have fields from the grandfather.

So, a good workaround . . .
joss buttlerjoss buttler
There are a few alternative approaches you could consider, depending on your specific use case:
  1. Use a numbered list instead of repeating field names: Instead of repeating the field name with a number, you could use a numbered list to keep track of each row. For example, the first row could be "Door 1: Name," "Door 1: Area," "Door 1: Type," and "Door 1: Location," and the second row could be "Door 2: Name," "Door 2: Area," "Door 2: Type," and "Door 2: Location."
  2. Use a nested object to represent each row: Instead of using a separate field for each cell in a row, you could create a nested object to represent each row. For example, you could create a "Door" object with fields for "Name," "Area," "Type," and "Location," and then create an array of "Door" objects to represent the rows in the table.
  3. Use a database or spreadsheet program to manage the data: Depending on your specific use case, it may be more efficient to store the table data in a database or spreadsheet program instead of creating a custom object in your code. This would allow you to easily query and manipulate the data using SQL or spreadsheet functions, and would also make it easier to import and export the data in various formats.

Overall, the approach you choose will depend on the specific requirements of your project and the tools and technologies you are working with. However, with careful consideration and planning, you should be able to come up with a naming convention and data structure that meets your needs and is easy to understand and maintain. Source https://qsmart.qa/services/av-solutions-company-in-qatar/