Well, good folk,

Here is a question for you.

In my mind there is one possible real use for one-to-one relationships: space saving - economic architecture. Let me give my example and see what you think:

Table: CONTACT

Fields: _id, name, email, tel, _id_billing_address, _id_del_add [simplified - but yes ADDRESS is to be separate table]

Now, for most of my say 90k contacts this is fine. All I need, but for 1k of them I need other data: picture, biography, iban, ni, bank, sortcode, ip, salary, username, department, etc etc

So purely for data economy i create a second table to hold this info in:

Table: CONTACT_INFO

Fields: _id_contact, 30 extra fields

Whaddya reckon? Or is FMP9 so space efficient that 90k times the 30 other fields i intermittently require above the normal 10 simply won't make a difference???

Cheers,

t

Edited June 27, 200817 yr by Guest

very helpful LaRetta, nice one. Duly noted… specially the indexed stuff. I'll add a minor conundrum later when I can illustrate it! :

Blessings on ya!

t

now here is another really crazy idea for a one-to-one relationship table use... tell me wot u think!

i'm well into FMS/FMA10... and i'm building a multi-user, multi-window hierarchy, pretty heavy duty. it works nicely, but its slow. Cos all calculated sort orders etc, lots of ways of improving this, but they tend to involve manually fixing descendant/parent attributes as i go along - moving children, deleting children, relocating families, reordering etc... - basically so it runs on indexed values rather than recursively calculated values.

Now here is where my One-2-One usage comes in - modify access is a pain - these records might be locked by other users, in which case i can't 'fix' them properly, can I???!?

However, if i store them in a one-2-one table, that is only used for these continually unlocked items, then their are calculation fields that are just calcs of these??? it should still be pretty fast, and won't have to go thru 8 levels etc of recursion for each displayed item to work out its various attributes...?

What do u tink? i'm already using such a method to guarantee i can *always* tamper with stock figures up or down as i need to...?

Appreciate your views...

ok,

this one caused me a fair bit of headache, and i've actually built this strange one to one machine editing only table... and it worked as a solution. But rather arcane and convoluted.

However, there was a more cunning way round it enabling me to keep just one table. It involves reading and getting to grips with:

Auto indexing article (by Ray Cologon)

I have had success with bypassing write access issues with multiple users via the indexed calculation triggered by a 'setfield[ someGlobal field in table; 1]' value - it updates the indexed calculation merrily without any write access complaints.

Can i be bothered to rework the whole thing? Arrrghh!!! i don't know.

But it'll save me trouble in future similar situations.

Hopefully it'll save you troulbe.

actually, the above solution does not work... only if unstored calc and refreshing it, but i need stored calcs to build relationships on, so my development and usage of a one-to-one table still seems (experimentally) the fastest possible way to achive my results. The force related lookup route is too slow to be workable on the scale i need it to be...

One day i might post a completed but fairly abstract fractional node hierarchy implementation that avoids renumbering as much as possible and is as fast as possible in a multi-user, multi-window context... however, at present mine uses my List & Dict tools 4 speed and handling, so its not really useable unless u have them...

and that's 30 custom functions, and seeming as few have been curious about them, except the extremists (and they can handle the hrc maths anyway)...

anyways, l8r on...

you are absolutely right, of course, LaRetta, i will do in time...

in the meanwhile these are a few extant published methods for hierarchies: ISO Magazine, Excelysis, Edoshin, Seedcode...

i'm on 2 weeks holiday now, and i feel i'll be experimenting for a while with hierarchy structure/FMP theory over next year or so, after that hopefully the abstract will appear... or maybe sooner a three quarter-baked version...?

enjoy the summer, T