Thanks for the example. That is SORTA what i was hoping for but thats a little too complicated.
Now as you can see there are a number of "Vistas" from multiple Brands. In the product section, i already have them labled as to which brand they belong to. I was just wondering if there is a way to make a PO for a certain brand, only show product available that is from that brand?
So if i make a PO for Astronomy, i only have the drop down menu to show Astronomy styles.
the demo takes a category and only allows choices from the appropriate sub-categories. I think that's what you want - maybe you need "brand - product - style" ? You can use any number of categories in your hierarchy (e.g. Size).
I'm not sure - it's very flexible for top-down data entry.
First of all, thank you very much for assisting. i do understand your set up. Im just trying to think how i would incorporate it into mine without having to re-code everything.
Is there a way to make it so it only shows that brand's styles in the drop down menu just by selecting the brand that ill be using? the way you have it, you keep selecting parameters until you get to the choice you want, and it fills in the style info.
so using that example, i would have to choose the brand, then the style, then the season, then color but even then it would narrow it down to multiple choices.
the way i do it now, is just type the name of the style, select it form the drop down menu and it fills in all the info associated with that style. which is fine, but im just trying to find a way to shave a few seconds off of my data entry.
plus that dark blue selector color makes it tough to see the style name.
With regard to Brands, do you have a Brands table? Do you have an ID code for each brand, or is it all by text selection (e.g., brand name: Astronomy. Brand name: Astronomy International)?
You can certainly get to what you're after. Please post either pictures of a relationship graph or a sample of the database.
First guess out of me? One way or the other you do a self join on the Products table. Something like Products links to Products_Brand when Products::Brand = Products_Brand::Brand.
The details depend a lot on what your structure is.
Im still somewhat of a novice on FM but the way i have it set up is i have the PO data base and the PRODUCT database.
on the PO i have STYLENAME01...STYLE NAME 20
Each STYLE NAME (1-20) has its own relationship table called PRODUCT MATCH 1... PRODUCT MATCH 20
Then it matches whatever i put in StyleName02 (for example) to the Style Name in Product Match 2 and then populates all the relative info to that style.
On each style, i have the Brand delegated by text selection (Astronomy, Ocean Current....)
Also, on each PO, i have the Brand delegated by text selection (Astronomy, Ocean Current....)
Im sure the way i have it set up isnt the most optimal but it works.
Hope this is enough info to help you help me. haha.
I mean, i guess i could make multiple databases, one for each brand, and then when i choose the Brand on the PO it will change the fields to match that of the brand?
If i put ASTRONOMY on the PO then the STYLE NAME fields will change to StyleName01Astro ... StyleName20Astro
If i put Ocean Current on the PO then the STYLE NAME fields will change to StyleName01OC ... StyleName20OC
Seems like the long way though.
multiple databases/tables (one for each brand) would be the wrong design. However a Brand table and a Product table would be appropriate. Then each product has the brand "id" (unique primary key field associated with the Brand) as a "foreign key". if both tables are related on these fields, then many things are possible.
but trying to get valuelists populated from different brand/product tables would be difficult.
if a product can have many brands, a JOIN table would be advantageous.
OOOOH... whats a JOIN TABLE? never heard of that one
Beverly: multiple databases/tables (one for each brand) would be the wrong design.
To add to Beverly's note, my design is not the right design either. I made it as a concept piece.
I think that the main point is to "not repeat any data". That is, ultimately, you'd have one table for every level of hierarchy, with serial numbers used as ID's representing the attributes on each of those levels. One table for PO's, one for brands, one for products, etc.
Ok this is starting to make a little more sense.
I have a PO table, and 20 Product Match tables (one corresponding for each Style Name foreign field on the PO table)
So if i created a Brand Table will it link in between these two tables or before one?
Im just confused on how i would set up that relationship.
Thanks again guys, i know its frustrating working with a noob.
JOIN TABLE is between two other tables and "mostly" has the ID's from the other tables and unique info:
Products::ProductID -> ProdBrands::ProductID
this allow a "many-to-many" relationship where a brand may have many products and a product may be produced by many brands (but have unique features for that product by each brand)
1 of 1 people found this helpful
You should really read up on data modeling and normalization.
This will give you a solid foundation and way of thinking about the data and how to fit it into the relational model.
Investing the time at the beginning will prevent you from having to redesign as you learn.