On 2010 Jun 22, at 8:32, Winfried Huslik wrote:
> Richard,
>
>> One Calculation Indexed, = 1
>
> I would strongly advice to refrain from the One = One relationships. These
> are relicts from the pre FileMaker 7 era. They tend to slow down operations
> significantly. If at all necessary use the "|X|" predicate, where you can use
> any two fields that already exist.
I do indeed use the "x" relator rather than the "=" relator, I just choose to
always apply it to the "One" fields, which are always there, at the top of the
field list, where I can find them easily. Indeed, much of the virtue of having
standard fields (with standard headers) is so I can quickly locate what I'm
after when building a database.
Besides, I often have other uses for a field that's guaranteed to have a check
in the checkbox, so "One" turns out to be quite a versatile performer for me.
(It's also the top item on every file's inventory of value lists.)
> I do not see a reason why every table should be linked to every other table.
> Use only links that have a real purpose.
As I said, I use the "F" table to store, among other things, the default values
to be entered in newly created records in OTHER tables. Having a link between
"F" and every other table means I can simply take it for granted when creating
a new field that REQUIRES a default entry that I can create the default field
in "F", knowing that I've already provided the necessary inter-table connection.
I also use "F" to store the table name, layout number, and record number of any
place I want to be able to return to quickly after gallivanting off to some
other part of the database to accomplish some quick task like checking how many
people share the surname of the current record, and that pretty much requires
me to be able to do so from everywhere.
> Use of Globals for storing constant values is not recommended since they
> loose their content when cloned or recovered.
True indeed, and something I discovered the hard way. Thus I am careful when
creating fields for the 1 and only record I have in the "F" table to avoid
Global storage for fields where I want ANY user to be able to change the value
for ALL users, but to employ it for those cases where different users need
their own personalized version of that particular field.
>> Table Calculation Unstored, = Get ( LayoutTableName )
>> Layout Calculation Unstored, = Get ( LayoutName )
>
> These unstored calculations bring no advantage over the function call as
> such. Use only where needed.
Since I display these fields at the top right corner of all my output layouts,
it's easier to just have a short name for them ready to rock'n'roll when I get
there. It makes it much easier when I'm doing phone support to have the table
and layout displayed so I can ask the user which screen he or she is looking
at. So I DO use them where needed, which is pretty much everywhere.
>> --- PASSTHRUS --- Text Global
>> (Note: calculation fields that assemble data fields from this table for use
>> in other tables)
>
> These can be avoided all together by setting up the relation graph
> accordingly.
But I don't WANT to avoid them. For example, I have various fields for name
components ("Name Title", "Name Pers", "Name Mid", "Name Fam", "Name Ext", and
"Name Nick") and I want to assemble them in various different ways for
different purposes. This requires calculation fields that operate on the name
components. It's easiest to just have ONE calculation field for, say, "Name
Full", with the result available in the table where all the components exist,
and then refer to that field from all the other tables that need to use it. And
having these calculated results readily visible under the "PASSTHRUS" heading
makes it easier to find them when I need to.
>> BeSeq Number Indexed, Auto-Enter Serial, Can't Modify Auto, Always
>> Validate, Required Value, Unique, Numeric Only
>>
>
> Auto-enter serial numbers require special care when updating tables or
> importing new data. I personally use an otherwise meaningless number, created
> as an auto-enter calculation:
> uid = GetAsNumber ( GetAsNumber ( Get ( CurrentTimeStamp ) ) & Right
> ("0000" & Get ( RecordID ) ; 5) )
> This way I never have to think about that serial number again. There are
> others, more complicated calculations floating around, but these seem
> overkill to me.
I don't see how this works any better for importing data than just using a
straight auto-entered serial number. What am I missing?
