FileMaker Pro Linking database relationships - relational-database

I am making a Data base to manage all the computers in my business, i have two tables:
1)lists all the serial numbers and computer ip address,
2)displays a form for me to write a diagnostic report.
What i want to do, is when i type the computers ip address into the form, i want it to look up the serial number on the linked table, and then automatically populate the ip address field in the form.

Step 1 is to establish a relationship between your two tables, which I'll call SerialNumbers and DiagnosticReports.
Presumably in your SerialNumbers table you have the following fields:
Serial Number
IP Address
And in your DiagnosticReports tabel you have the following fields:
Serial Number
Notes
IP Address (if you want to capture the IP Address at the time you capture the note. This is not necessary if you always want to show the current IP Address for this serial number.)
In the Relationships tab of the Manage Database window (File Menu > Manage > Database > Relationships Tab) you will need to draw a line from the "Serial Number" field of the SerialNumber table to the "Serial Number" field of the DiagnosticReports table
SerialNumbers::Serial Number >----< DiagnosticReports::Serial Number
From here you have a choice to make. Do you want A: To store the IP Address at the time of the Diagnostic Report or to B: Show only the current IP Address for this Serial Number.
To do A, store the IP Address at the time the Diagnostic Report is made:
Go to the Fields tab of the Manage Database window
Select your DiagnosticReports table
Set the IP Address field to Auto-Enter the Looked-Up value from the SerialNumbers table for the IP Address field
To do B, show only the current IP Address for this Serial Number:
While editing the a layout displaying data from the DiagnosticReports table, drag a new field onto the layout.
Select the table SerialNumbers and the field IP Address.

It sounds like you can do it all with a single table.
Columns are:
Serial Number
IP Number
Description
Notes

Related

Should you put USER data in tables within a single MySQL database, or have a separate database for USER data?

Is there an advantage to separating user data into a separate MySQL database from the main application database? The number of tables in a db can add up, and separating them by function seems a good way to reduce the clutter.
The way I was told to think about your database data is that if you are going to be referencing the data again it should be in a separate table, just like if you are likely to enter the same data more than once it should be in a separate table and then linked or joined.
Using a separate Database is a little excessive.
For example lets say you have a user, who has an email address and a postal address.
There is a chance that the postal address could be used by more than one user (family members for example) so I would then put the User, eMail address and Postal Address into different tables each using the User row id as a join between each table.

Should I store users IP addresses in a separate table?

I am building a new website that will store IP addresses in multiple tables like users, login_history, payments and more.
I am wondering if I should add an ip column in each table and store the actual ip, or I should create a separate table named ip_addresses and store the ip identifier in the columns.
Method 1:
users:
username | ip
jon_snow | 134744072
Method 2:
users:
username | ip
jon_snow | 1
--
ip_addresses:
id | ip
1 | 134744072
Since IP addresses will change for most of the users over time, the best place to store them is perhaps in the login_history table. This way you can associate the IP addresses with the users and their sessions.
Of course, if you want to restrict user access based on IP address and you rquire your users to use the same IP over the time, then store it in the users table.
IPv4 addresses are meaningfully formatted 32-bit integers. IPv6 ones are meaningfully formatted again, but much larger. Either way, you'd be creating a 1:1 mapping of dense data. Unless you need to do it for other reasons, I would not normally choose to normalise them into another table. You're unlikely to gain speed or save space, unless your users have a very restricted set of IPs.
The used of inet(6)_aton will pack string representations, and the _ntoa version will unpack them efficiently, so you can use meaningful strings and store efficient binary versions.

user verification value - where to store

Quick question as relates to database.
Where would you store the value of "UserVerified"? (The one that occurs after the user has checked his email and clicked on the "Verify" link with the hash value at the end).
Would you store it in the User table? (Along with username, hash) ?
Or in the UserProfile table (along with first name, last name, email, phone, etc) ?
Please note that both tables will always contain 1 entry for a user, such that when a user is created, automatically a userprofile is created as well.
This is all up to your preference. I would figure out what you want it to be more related to, the account as a whole, or to the email address. If it is more related to the account and determines if the account is active, then store it in the User table. If this is more related to the email address and that it is verified, then store it in Profile table.
Again though, especially since the tables are 1:1, it doesn't really matter other than relation and readability.

database design issue...for booking app

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.

Can I have more than one record with same user info except phone number in mysql

Can I have same username and email in a table but different phone number where phone number is kept in another table with the id of user table.
One more thing if I put same user info record more than record in one table that is user table with different phone number in that table(Not by putting by foreign key concept in another phone number table) so what id the problem.
I am new to database please make me clear my concept.Please help me.
yes you can have same username and email in a table but different phone number by making
GROUP BY phone_number
Do note: That you will be selected more than one row for users who has more than one phone number, which may not be ideal if you are looking for a simple result of users. So you may want to consider the queries up.