Our busness is in the process of migrating from FM6 to FM10. Big jump and
steep learning curve for those of us doing the redesign (and running the
business at the same time I might point out). Of course some of the biggest
differences between 6 and 10 are having a single 'database' instead of
separate files for each table, having the visual graph to setup and maintain
relationships and the ability to set a relationship on multiple keys.
Everything is jostling along fairly well with our relationship graph getting
more crowded by the day with multiple instances (or views) of the same
tables, depending on how you want to filter your recordset in a
layout/portal.

Then along comes FM11 with 'portal filtering'! This looks real sweet at
first blush but I'm wondering how much re-design I should do because of it.
If one were to take this feature to the extreme you could set a single
relationship into your child table (ex - interface into transactions where
interface::global_filter<transactions::transID with global_filter being set
to 0 and transID being an AE serial number). That would provide visibility
of ALL records in the child table which could then be filtered at will in
portals. My quandry is - how would this type of design affect performance if
the transaction table has 100K records and growing?

<<As a side bar (and I'll open another thread if need be), the transactions
table is currently a native FM10 table. We also have MySQL on the server and
want to use it for the backend data. I'd like to have answers to the same
questions concerning performance if we were to make this change.>>

I confess I know little to nothing about the inner workings of FM. In a
previous life I was able to create and break relationships on the fly with
script commands (and sure do miss it). But if I try to compare what FM is
doing to a SQL 'select' statement it would seem that the relationship would
be the 'where' clause and the portal filter would be the 'having' clause.
Does this make sense to anyone?

Is there any authoritative reference that addresses schema design vs
performance and server load? Can anyone share their thoughts on how 'portal
filters' will impact their database designs?

GSteven wrote:
You absolutely, positively DO NOT want to do this!!!!

Portal filtering is fine for filtering a record set down from a few
hundred or maybe a thousand or so records. But it is NOT meant as a
substitute for relationships. It is SLOW, SLOW, SLOW. And if you have
your portal sorted, as well, then forget about it.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg
FM Professional Solutions, Los Angeles
Member, FileMaker Business Alliance

Howard,

Good to hear from you. I'm glad you weighed in on this and I can certainly
see how that would be the case.

I need to do my homework here I guess and take a fresh look at my
relationship graph. It certainly is complicated and resembles the classic
spider graph. A result of developing on the fly without a proper design
process.

Thanks again,
Steve

"Howard Schlossberg" <howard (AT) nospam (DOT) fmprosolutions.com> wrote

"GSteven" <GSP@DavClaServ> schreef in bericht
news:85d57$4b995575$d1a8fa82$13678 (AT) EDELTACOM (DOT) COM...
You wrote you are currently redeveloping from 6 to 10. Then you end up with
a cluttered, unreadable spider-graph and you would have to re-learn and
redevelop again. Start putting in some learning now, before you go ahaid.

I would advise:

http://developer.filemaker.com/conte...odeling_en.pdf

and

http://www.filemaker.com/downloads/p..._ConvNov05.pdf

but there are others as well.

--
Keep well / Hou je goed

Ursus

I agree with Howard. Listen to the latest filemaker talk podcast.
At one point they discuss the fact that the portal filtering feature
in 11 is purely a display feature. It does not effect or exist in the
schema of your database. For example, if you filter a portal, and
then do a Go To Related Records using the relationship of the portal,
you will go to ALL related records, not just the ones displayed in the
filtered portal.

As far as a great training ground for filemaker www.filemakermagazine.com
has awesome training videos, although sometimes pretty advanced stuff.

If you would like beginner to advanced training www.vtc.com has a
complete filemaker training series.

Darren Burgess

On Mar 11, 7:58*am, "GSteven" <GSP@DavClaServ> wrote:

A relationship is like a SELECT and portal filtering is like a SELECT
as well. HAVING is really for grouped records.

G