Sam0316 Posted November 1, 2016 Posted November 1, 2016 (edited) Hello everyone, i am new to filemaker. Recently, i am developing a tour database to my client. So there are 4 tables. University, Hotel, Airport and School. i have considered to use portal to present my data so i create Tour table and tour details table and link them up. The tour guide of a specific people will be shown in tour details table. Due to the difference of these data, for airport, flight time, airport, check-in time and check out time. For school, address, school name, visit time, etc. i use hide function to hide the unwanted fields when the user choose a specific category which is a text field. In the tour layout, the user can choose the catagory first, and using conditional value list, they can choose the name ,address. which is shown in attached file. in order to make the condition value list work. i create tour list table to store name, address of the 4 tables so i need to write a script to copy the data from these 4 tables to tour list table. i think it is not a good practice to copy data from one table to another table. Does anyone have any idea how to work with this problem? one suggestion is to combine 4 tables into one so i could avoid copying data, but there are different data store in 4 tables respectively. Is it a good idea to combine them all, will it make the whole table too complicated in the future as different types of information store in 1 table. My description may be unclear to all of you. sorry about that. The sample file i wrote using filemaker 11. Test.fp7 Edited November 1, 2016 by Sam0316
Wim Decorte Posted November 1, 2016 Posted November 1, 2016 The main question for now is whether those 4 tables should be one or not. What is the real entity that they store. If you think of it as an "arrangement" or a "booking" then university / hotel / airport / school becomes just a 'type' attribute of the booking and one table will suffice and they are not really different types of information.
Sam0316 Posted November 2, 2016 Author Posted November 2, 2016 14 hours ago, Wim Decorte said: The main question for now is whether those 4 tables should be one or not. What is the real entity that they store. If you think of it as an "arrangement" or a "booking" then university / hotel / airport / school becomes just a 'type' attribute of the booking and one table will suffice and they are not really different types of information. Thank you. There are other information store in school and university respectively.For example, email, contact, system, organisation etc. On the other hand, the university store the undergradrate population, GPA, interview policy, etc. so in this case, is that ok to combine them into one. As number of records increase annually, will it be difficult to manage the data?
Wim Decorte Posted November 2, 2016 Posted November 2, 2016 14 hours ago, Sam0316 said: As number of records increase annually, will it be difficult to manage the data? Depends on how much data and what you want to do with it. FM is a database so it is built to contain lots of data. Sometimes it is harder to manage data and report on it if the entities are not defined properly. If you expect a lot of data then stay away from calculated fields, especially the unstored kind.
Sam0316 Posted November 3, 2016 Author Posted November 3, 2016 9 hours ago, Wim Decorte said: Depends on how much data and what you want to do with it. FM is a database so it is built to contain lots of data. Sometimes it is harder to manage data and report on it if the entities are not defined properly. If you expect a lot of data then stay away from calculated fields, especially the unstored kind. If i combine them into one table, i need to create 4 layouts using same table with corresponding fields. But one problem is the school table links to other table for other application.
Recommended Posts
This topic is 3010 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now