Imagine the following; i have an record in one table representing an service. Another table with user accounts. The Service record has two fields where in the first an tech user and in the second an billing user can get selected.
/ - Contact Tech -\
SERVICE - -> USER
\ - Contact Bill -/
How can this get designed in filemaker 14? When i try to design this, Tech and Bill are always equal. If i change one the other gets changed as well.
Your question is not entirely clear. Please explain in more detail what is being tracked here.
On the surface, it seems that Users subscribe to Services. This would be a many-to-many relationship, as each user can subscribe to multiple services, while each service can be provided to multiple users. To resolve this you would require three tables:
Users -< Subscriptions >- Services
The Subscriptions table would hold an individual record for each instance of a user subscribing to a service (this is known as a join table). The contact details would be fields in the Subscriptions table.
You can link to the same table as many times as you want. Use a deferent Foreign key to link each user.
E.g. use fk_UserID_Tech to link the first user and fk_UserID_billing for the second user. In the "define database" you can link to another instance of the same table, so your diagram will look like this:
/ - Contact Tech -> USER_Teck
SERVICE -
\ - Contact Bill -> User_Bill
Both instances - USER_Teck and User_Bill are the instances of the same table - Users. They are called Table Occurrences.
Related
I was doing a mini project on Cryptocurrency tracking. I have a Users table in Mysql to store the details of registered users in my webapp.
When user logs in, they can see a table of cryptocurrencies. They can add a specific cryptocurrency as favorite from that table by clicking a button.
Now, when they click that button I want to store the id of specific crypto in a table. Since one user can add more than one crypto as their favorite, I can't store the CryptoId in a single cell. So, my requirement is, I need seperate "Favorite" table for every user. Whenever a new User registers, I want to create a new "Favorite" table for that user. How can I achieve this?
Please give me any solution or advice on this, or any alternative Idea on how I can implement this requirement of mine.
What you need is a many-to-many relationship table:
Users:
user_id
username
...
Crypto_Currencies:
cc_id
cc_name
UserCCFaves:
user_id
cc_id
Each time a user adds a favorite, you put a record in UserCCFaves linking the user and the crypto currency
Many-to-many relationships examples
I am fairly new to MS Access and looking for a solution regarding a form I am trying to build. The form should be used to show different user entries and to create or modify users.
The problem I am blocking is for a combo box and a many-to-many relationship.
I have several tables which combined provide me the information I use to build the form.
My first table Users provides me information about *first name, last name etc. *
A second table Servers includes the list of different country servers a user can have access to.
Since an user can have access to different servers/countries and a country/server can have different users I am confronted with a many-to-many relationship. Therefore I created a junction table which includes the userID as FK (from the User table) and the ID as FK (of the country/server from the Servers table).
What I am trying to achieve now but where I am blocking is:
to have a combobox which lists all available servers/countries
mark the entries which are linked to the user record which is shown
e.g.
Servers: Belgium, Germany, Netherlands, Sweden, UK
User: John Doe => access to Germany & UK
list/combobox should show all countries but select only the ones John doe has access to (when record John Doe is selected)
Is there any way to achieve this and what needs to be done ?
I am also open for any other solution if this cannot be done via a combobox.
Thanks for the help.
I have 4 tables,one is credentials(it holds an id, email and password), the other 2 are for business users and regular users of the app.
The business users table holds crID(foreign key)name,lastname,address etc...
The regular users table holds crID(foreign key),name,lastname etc...
The 4th is the booking table, it holds a bookingID, bookedfrom,bookedfor(the last 2 being foreign keys that point to the credentials table).
If a regular user registers in the site he closes a bookingslot and that is stored in the booking table, his name,last name are stored in the regular users table and his credentials in the credentials table.
The business user table just holds the business user for which a booking is made by the regular users.
Here is a graph:
db image
The question is what to do if a regular user does not choose the web to make the booking but makes a call. The business users are given the option to make the booking "manually" also. I am just having difficulty how to integrate that in the db.
As I see it I need to make the following:
Create a booking slot in the bookings table
Create a new regular user entry in the regular users table and at the same time create another column that would indicate if the user is registered or not.
create an entry in the credentials table but without password/email since this he will not be a registered user...he just made a booking using the phone.
WHat is your opinion.If you want I will post some show create statements. I think I made my point.
I would personally merge business users, normal users and optionally credentials in one single userstable.
Since I don't see the need of two seperate tables for your users, it would simplify drastically your data model. You just need a flag to determine if the user is a business user or a normal user.
For the rest, I think that having a null password is enough to determine if the user hasn't registered yet.
For an ecommerce site that allows both Guest checkouts and registered user checkouts, how will you handle the 2 different customer groups?
Do you store both groups in the same table customers which has a foreign key customer_group_id pointing to another table customer_groups? In this case, will you worry about duplicate guest checkouts "polluting" the customers table?
How will the information captured for the 2 customer groups be different? I am thinking the difference is that the guest checkout customers will not have a password thats it.
I store customer information directly in the order rather than rely on the information in the customer record. That does a couple things:
I don't have to have a guest user in the customer database
If my customer information changes, or if a customer wants to ship one item to one place, and another item to another place the information about the order will still be correct.
I view order information as historical data. It should not change because something else in your database changes. For example if I order something from you, and at some later time I move and update my billing and shipping information, you should still know that the previous order was billed and shipped to the previous address. If you rely on the relationship between the customer and the order to retain bill to and ship to information, Once I move and update my profile, you think you shipped to my new address. You may not see that as an issue, but it will be.
You can still get the current information from the customer record to populate the fields on the order if the customer has an account. For a guest, he has to type it every time.
The common entity is a Checkout. The guest checkout would be a null FK link on the checkout entity to a registerd user entity.
Good Day,
I'm currently designing database structure for a website of mine. I need community assistance in one aspect only as I never did something similar.
Website will include three types of the payments:
Internal payments (Escrow kind payments). User can send payment to another user.
Deposits. Users add fund to their accounts.
Withdrawal. User can request a withdrawal. Money will be sent to their bank/PayPal account.
Basically, I need some tips to get the best design possible.
Here's what I'm thinking about:
deposits - this table will store info about deposits
deposits_data - this table will store info about deposit transaction (ex. data returned by PayPal IPN)
payments - table to store internal payments
withdrawals - table to store info about withdrawal request
transactions - table to store info about ALL transactions (with ENUM() field called type with following values possible: internal, deposit, withdrawal)
Please note that I have already a table logs to store every user action.
Unfortunately, I feel that my design approch is not the best possible in this aspect. Can you share some ideas/tips?
PS. Can I use a name "escrow" for internal payments or should I choose different name?
Edit
DEPOSITS, PAYMENTS and WITHDRAWALS tables store specific transaction details. TRANSACTIONS table stores only limited info - it's a kind of logs table - with a details field (which contains a text to display in user log section, ex: "User 1 sent you a payment for something")/
Of course I have users tables, etc.
Can I use a name "escrow" for internal
payments or should I choose different
name?
Escrow has a specfic financial/legal meaning, which is different from how you seem to mean it: "a written agreement (or property or money) delivered to a third party or put in trust by one party to a contract to be returned after fulfillment of some condition" (source)
So choosing a different name seems like a good idea.
As for design, what data will DEPOSITS, PAYMENTS and WITHDRAWALS store which TRANSACTIONS won't? Also, you need an ACCOUNTS table. Or are you planning to just use your existing USERS table (I presume you have such a thing)? You probably ought to have something for external parties, even if you only intend to support PayPal for the time being.