Similars?

[JeanR]

I apologize if this question is too basic. I've noticed that Similars are used in tables.. but have yet to find out exactly why and what they are.. Is this a FileMaker thing.. couldn't find any explanation in my FileMaker book or in the Help menu.

They seem to have to do with keys... thanks for your help with this.

Jean

[mr_vodka]

Is this your system or the diagram of a sample database that you got from an exercise etc?

[JamesBand]

What you are talking about is a technique as old as Relational Databases themselves... and it is not exclusive to Filemaker. It does indeed have to do with keys... In the case of your tog (table occurrence group) shown in your image, you have both primary and foreign keys.

What you really need is a book on basic database design and filemaker. But let's have a stab at, what will hopefully be, a rudimentary explanation.

You obviously have projects, clients and contacts.

Each project has a primary key. That key is established at the time of the records creation, by the system. You want the system to do this, so that there will not be duplicates. That key is what remains constant, no matter what else you may change in that record. That way, it can still be found, if you for instance you change the title of the project. (The same applies to clients and contacts.)

Now let's talk about foreign keys. They allow you to link the, in this case, project to your client. This can be 1 to 1 or 1 to many. 1 to 1 being 1 project - 1 client and 1 to many being 1 project to many clients. It is foreign, because it stores the primary key of another record from another table, in this case a client.

All the above would apply to the relationship between your client table and your contact table, and so on.

BTW, on your tog, the _P_ is for Primary and _F_ is for foreign.

I hope that this helps.

[Søren Dyhr]

It's even worse, it's the second time around within a fortnight, it's probably from the business productivity package or similar.

It's the method used here, making relational links (selfjoins) on the raw entries including typos ... as you might notice isn't it what I wholehearted support, and certainly not by having constants in the main table.

The structure in you image seems to be a recursive structure with clients and contacts, but I do not see why there then is a 1NF violation in the very table? Why isn't Address details broken out in it's own tagged table, where zipcode and city and similar are individual records in a table.

There are several ways to do this, one of the more intuitive ones is David Kachels tiered tables mentioned in his white-paper for novices, on page 15-16.

This method largely reduces the need for excessive fields facilitations in one table, since a new record is generated by each field'ish entry is it only necessary to make linking to similar on a stored calc field returning text, getting the various field-types to typecast into text. You just need a foreignkey for each type.

--sd

[JeanR]

Thanks for your response. I grasp the concept of primary and foreign keys but sometimes it's difficult to understand exactly how to connect the tables.. it's a learning curve so that's why I like to look at templates and FileMaker dbs to see what someone has done. Of course, that also means I don't understand everything in them..

Are similars something that one consciously adds or are they created as a result of other fields and relationships? I guess I'm still not totally understanding "how they appear in the table."

Thanks.

Jean

[Søren Dyhr]

Similars is what you group by in subsummary reports, vanity dictates however developers to present such in portals changing a global field to show found sets accordingly.

Filemaker is as such not really a database in the strictest sense, but merely a presentation tool for information, where everything are desired with as little scripting as possible - this is design objective filemaker Inc. have desided to occupy as niche, because it makes it stumbling near the next step after a spreadsheet, and where programming as such is considered inappropriately geek'ish.

Linking self-joining is considered easier to grasp!

--sd

Edited March 11, 2008 by Guest

[JamesBand]

Given SD's comment I'd say that this might not be the best example to study... You might start with your problem and work it through on the forum. For instance, in what situation (exaclty) would you benefit from being able to identify similar records? Start from there and let the community help steer you through the problem.

[aldipalo]

Hi Jean:

In response to your basic question. In your example TOG each similar TO separates a specific. I.E. 'Contact_Similar_Company' will show you, in a portal, all contacts at that company. Contacts_Similar_Name' will show you all contacts with a similar name at any company. (Of course you could use 2 fields Contact Name and Company and filter for all contacts with the same name at the same company) It is just a way of filtering data through self joins.

HTH