Creating applications in Fabrik (and in a larger context designing a database) can be a fun and rewarding exercise.... or can be a series of frustrations.
Lets imagine that we want to make a shop application.
The key to success is planning, so first of all - turn off your computer, get out a pencil and some paper. Having a diagram of what you want to achieve in is indispensable and will save you hours of frustration later down the line as it forces you to make decisions about your application before you start building it - a pencil and a rubber are so much faster that getting half way through your application before you realize that a fundamental mistake has been made.
Now with your drawn diagram you are going to try to describe what objects and relationships you are going to have in your application.
Objects are fairly straight forward, the are things like "products", "customers", "manufacturers" and "orders", any noun in your model can be thought of as an object.
Often when we think more about these objects we realize that they contain other objects. Customers contain "addresses" (they could have a credit card address AND a different delivery address). Orders are actual made up of "Order items" - each product that the customer has placed with any given order.
So break down these objects as far as they will go. Then on your piece of paper draw a box labelled accordingly for each object.
Relationships are a little more abstract and take a little more thought about how we want our application to work. Rather than nouns, relationships are verbs.
At their simplest they are defined by drawing a line from one object's box to another - so we could draw a line from products to manufacturers, which would indicate that a product is created by a manufacturer. Note how "created by" is a verb and hence a relationship.
In this example a product is created by ONE manufacturer and manufacturers can create MANY products. This type of relationship is know as a "one to many" relationship and can often be created in Fabrik by use of a database join element, or by adding a join to the Fabrik table.
Now taking our shop example, lets say that "products" can go in "categories" BUT that any single product can be assigned to multiple categories. This is a "many to many" relationship and thus we need to create a table for it. This table will have a field to store the productid and another to store the categoryid.
I tend to name these types of tables "product_categories" as its name describes the relationship it is modelling. A component like Virtuemart has a similar naming convention but adds "_xref" to the end of the table name.
This thought process is referred to as database normalization - here's some further reading on it:
Some of our tutorials that deal with modelling these relationships
Tutorials in Wiki:
Tutorials in fabrikar.com (you have to log in at fabrikar.com, **: for Bronze subscribers only)