Building relations between tables

[Lacy]

Can you use a checkbox field as a key for another table?

 

What I am trying to do is have a different table come up depending on what is checked in the checkbox.

 

My goal is to have a different set of fields come up dependent on which laser head is being used. There are 3 different templates for data, and 7 heads. If the SR, SRA, or HR is checked, then the fields for the data they use needs to be there, but if the ST or Matrix head is checked, then the fields are different, as they are if the Vela heads are selected. Can I do this?

[Maarten Witberg]

My standard reaction is: don't put similar data in separate tables. However, you have not given us a lot to go on. I can grok that there are different types of information to be stored for different laser heads. To give good advice on how to proceed, I'd like to know more. Can you describe the information you want to store for each head?

[Lacy]

Thank you for your response.

 

Each head had slightly different settings that are important. For example, the number of shots fired on the left side and right side of the face have to be equal, the optical energy and radio frequency energy are different for each head and the skin type of the person getting the treatment. I hope to make the procedures paperless by allowing the practitioner to input the settings directly into the database, as well as keep track of the patients, types of procedures, dates and number of sessions, etc. I am very new to FileMaker (this is my first attempt at a FileMaker database) and I have only taken 1 class dealing with Access about 2 years ago, so I am VERY ignorant about this. Unfortunately, I live in a very small town, and there is no one here that I can get any advice or help from. Leaves me feeling a bit stuck.

 

I do know that I need to get my database designed before I build it, so I am trying.

[Maarten Witberg]

Perhaps you should try this book: filemaker pro 9 bible. I do not have it however the author asserts that it is aimed at beginners as well as experienced people.

 

As to your question, so far it sounds like you could very well do with one table that describes the technical specs of each laser, with a field for each spec. then a table of patient data and a table of treatments or procedures where you link the two.

 

In designing a thing like this, it is very important to know the protocols or procedures that a user would follow. Go to the day's work you normally have , from patients calling you up, consultations with the practitioner they may have, and how the practitioner would decide on choosing a treatment and selecting the appropriate machinery and machine settings. Describe what he would input into the database and which information he needs to have at the ready in the database. If this is for medical or semi medical purposes, perhaps you should look into quality assurance and or certification standards. (I have no knowledge if they even exist).

 

Then you can start devising how the database should look. Make pen-and-paper mockups of computer screens he sees at each step.

 

Then you can start designing the database structure.

[Techphan]

Keep all of the laser fields in one table. Design your first layout to contain the fields necessary for the first laser, then copy the layout for each additional laser type and re-arrange the fields as necessary.

 

Then have the choice of the laser (several different ways to accomplish this: separate buttons, drop-down list with script button) take you to the correct layout by script.

[Maarten Witberg]

Design your first layout to contain the fields necessary for the first laser, then copy the layout for each additional laser type and re-arrange the fields as necessary.

I think that this may be a necessary step, but from the information in the posts by Lacy so far, I am not convinced that it is. There is not enough information to go on in my view.