Multi-Processor Utilization and DB Design

[Rich K.]

Hi --

I have been reading posts the better part of today, that FM Server 10/11 takes advantage of Multiple Processors. However, that is usually followed by some murmurings about DB Design. Can somebody please clarify these DB Design "sins" that are so damaging, so that we all may avoid them to the best of our abilities.

Thanks in advance,

--Rich

[Steven H. Blackwell]

They are numerous and all too frequently encountered. Here are but a few:

1. Lots of subsummary fields that have to calculate every time they are displayed.

2. Excessively long list views.

3. Complex graphics.

4. Excessive number of multi-hop relational queries across the Graph.

5. Excessive number of fields in a table.

6. Working on all records when a subset of records is more appropriate.

7. Not freezing windows when appropriate.

8. Replaces or imports in List View or in Table View, when Form View is more appropriate.

There are many others; perhaps other contributors here can suggest some.

Inadequate server hardware is also a critical matter, of which processor configuration, as suggested by this thread, is one key element.

Steven

[bcooney]

9. Sorted/Filtered (not by relationship) portals.

10. Looping in a list view, especially one that contains unstored calcs.

[Steven H. Blackwell]

11. Excessive number of users calling complex finds on indexed fields at or about the same time.

Steven

[Vaughan]

How FM Server takes advantage (or not) of the server hardware is something that we developers have little control over; and nor should we need to. Databases should just go faster when running on better hardware. FMS and FMP should be doing whatever is necessary to make that happen at a very fundamental level way below our "FMP database" abstraction.

Efficient database design should always be a goal.