Dr. Evil Posted May 3, 2012 Posted May 3, 2012 How do you establish the "Owner" record in the CompaniesTable? CompaniesTable contains Owner, Clients and Vendors records. The database system needs to know which record from CompaniesTable is the operating Owner. So⦠I have accomplished this using a SystemTable. DEMO file and screen shots attached to help illustrate question. I just wanted to get a second opinion on this structure. Good or bad and needs work? The SystemTable is a "one record" table. SystemTable has a CompanyOwnerID field to set the Owner in. ALL other tables, ProjectsTable for example, have a hard calculated field that simply = 1001, the SystemID. This field connects the ProjectsTable to the SystemTable and in return establishes a link to Owner Record which. The hard calculated SystemID field in ALL parent tables; should this actually be a "calculation" field? It is really not calculating anything per say, it just needs to equal the one-record SystemID, always and forever. Technically is is calculating, but you see my point right? lol Also, should the SystemsTable be a one-record table, or should it be a NO record table and simply store global values? Some developers have a separate table just for the "owner" record. A one-record table. But this will not work in my particular case, as well as others if I understand correctly. THANKS A BILLION for any help on this topic! :) owner.fp7.zip
Vaughan Posted May 3, 2012 Posted May 3, 2012 Global values cannot be "stored" easily. A one record table is what I use.
Dr. Evil Posted May 3, 2012 Author Posted May 3, 2012 Great, so the one-record SystemsTable I will continue to use. Thanks Vaughan!
Vaughan Posted May 3, 2012 Posted May 3, 2012 I also have a "system" table that stores stuff that the solution needs to work with, like icons, images etc. Generally the user's don't get access to this, which is why I have a separate table that they can see edit.
Dr. Evil Posted May 8, 2012 Author Posted May 8, 2012 Vaughan! Thanks! Yes, in my solution it is the same. The one-record SystemTable is only accessible by Admin and stores like you mentioned icons, images, etc. Generally speaking; So is it safe to say, you would link the SystemTable via relationship to ea. TOG? Or in other words link the SystemTable to the "main" parent table of the TOG? On establishing a link between SystemTable and MainParentTable in TOG; The manner in which I mentioned at the beginning of this topic, is it a best practice technique? or is there a better way to do this? Thank everyone for your time and help on this topic! :hairy:
Vaughan Posted May 8, 2012 Posted May 8, 2012 This is where global fields can be helpful: globals can be accessed from any context at any time, even completely unrelated. Many developers use a startup script to load the "normal" values into global fields, and then reference the global fields. This avoids TOs to the preferences table everywhere. It does require that the startup script run before the solution works correctly, which can be a failure point.
Dr. Evil Posted May 9, 2012 Author Posted May 9, 2012 I do use globals for icons, images, misc. And yes, this makes it easy to access without a TO's everywhere. BUT, practically EVERY TOG in the database needs to know which Company record is the "Owner" record. So I'm thinking I will not have to relate every TO to the SystemTableOwner > CompanyTable, just the main TO in the TOG. Generally speaking. Heres kinda how I'm reading all this... So the SystemTable would be a one-record table with a SystemID. All MainTables will have a hard calculation field that = SystemID, that would link to a SystemTable TO, which would relate to CompanyOwnerRecord. The SystemTable would also have global fields for things like icons that could be accessed w/out a direct relationship. Would need a housekeeping script for this. Am I following correctly?
Vaughan Posted May 9, 2012 Posted May 9, 2012 All MainTables will have a hard calculation field that = SystemID, that would link to a SystemTable TO, which would relate to CompanyOwnerRecord. That's 6-think. Read up on the X-join operator, and rejoice.
Dr. Evil Posted May 9, 2012 Author Posted May 9, 2012 Yay! Rejoicing... Thanks Vaughan! From my read up, the x-join is a cartesian product: http://help.filemake...n-filemaker-pro So I have attached a new demo file using the x-join and SCRAPING the unnecessary constant calculation SystemID_field. Takes advantage of the x-join by using the already existing primary ID field in the tables. So any opinions on this structure? Solid, good practice system? Thanks for any feedback! owner_demo.fp7.zip
Recommended Posts
This topic is 4641 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