I want to handle data like id,name,and ladlinenumber. The landline number can be null for those who don't have.
Here the question is can I go for one table in mysql with above fields and making landlinenumber column as null for whom there is no value or can I create another table which told ID and landlinenumber.
Which is best way of doing.
If there is a chance of having one person with multiple landline number then you can have another table with id and landline number. Other wise just go with null in same table
Create a table with id,name, and ladlinenumber.
ID should be primary key with auto-increment
Name -NOT NULL
ladlinenumber - NULL
There is no need to create the separate table to store the ladlinenumber
Related
This question already has answers here:
Is storing a delimited list in a database column really that bad?
(10 answers)
Closed 3 years ago.
I want to store user information in Mysql for my Python Program.
One of the things I want to store is username history (static list)
Another is which groups they are a member of (dynamic list)
I am new to storing data in Mysql so am trying to figure out the best structure to achieve this. It seems like I could create 1 table for each user and have the name hsitory as a column, but everything I read tells me this would be wasteful and inefficient.
so for example....
Table = users
user_ID | current_username | username_history | groups_joined | groups_banned
========|==================|==================|===============|==============
01567 | Dave |Michael,Geoff, |group1,group2, |group4,group5
| |Bob,Nigel,Colin |group2 |group5,group7
========|==================|==================|===============|==============
01568 | Fred |Martin,Simon, |group3,group4, |group4,group3
| |Leo,Nick,Arthur |group6 |group2,group12
My first thought was to do something like the above and when I have a list to store like username_history I would convert the list to a string with comma seperated values and store it in a LONGTEXT field as shown. Then to add usernames as the user changes them I could use concat to add to the string.
This would work I guess, but it feels ugly and im sure there must be a better way. Also I think this would be very inefficient if I needed to search for a name in username history, find out all users that were called Fred for example.
My next thought was to create an entire table per user and populate the username_column with one name per field.
But googling around I found similar questions from database noobs all with replies saying this would create thousands of tables and be very inefficient.
ok so now im looking at relational tables (correct terminology??)....
table = username_history
user_id | usernames
========|==========
01567 | but I still need a list here....
I'm sure this is a very common problem for beginners, but I just can't seem to get my head around how the structure for my usage would look.
Thanks to anyone taking the time to help and advise :)
Create a table username_history with:
create table username_history (
id int not null auto_increment,
user_id varchar(10),
username varchar(30),
created_at datetime default CURRENT_TIMESTAMP,
primary key (`id`),
index (user_id)
);
You can then get the usernames in list format using GROUP_CONCAT-function.
You really need three tables:
Groups
Users
UserGroups
The first contains a list of the groups which user may join. It could be as simple as a unique ID and Group Name.
The second table is similar to your table in the question. For this purpose, the only columns we are concerned with are the unique ID for each user and their user name.
The third table has two columns: user_id and group_id. When a user joins a group, a row is inserted into this table with the unique IDs of the user and group.
You could also have a column with a timestamp of when the row was added, and a column for the user's status if needed.
The timestamp column would let you know when the user joined the group.
The status column could indicate if the user is banned from the group, or if the user left the group.
Im here with a little problem with my inventory and I've been pondering with idea of this little schema here.
Is it possible or is there another way I can achieve this kind of schema below?
I can cheat my way through this problem by just having my application identify what itemID should be inserted into the tbl_stocks but I fear when the ID of either medicine or bandage is updated, that would leave an issue in my tbl_stocks.
Any suggestions on how to achieve my target?
Normally you have 2 entries in such a table that can became different shapes.
So add a reference for both tables to tbl_Stocks one column Medicine_ID VARCHAR(10) NULL and a Bandage_ID VARCHAR(10) NULL
So of curse you have a null column in this table for every entry, but later you can easy join this table.
If more and more tables come as expected you need a crosstable for each "Shape" .. One Medicine_ID x tbl_Stocks and one Bandage_ID x tbl_Stocks. This is fast and a good design, but also brings more maintenance effort.
our database contain 5+ tables
user
----------
user_id (PK) int NOT NULL
name varchar(50) NOT NULL
photo
--------
photo_id (PK) int NOT NULL
user_id (FK) int NOT NULL
title varchar(50) NOT NULL
comment
-------
comment_id (PK) int NOT NULL
photo_id int NOT NULL
user_id int NOT NULL
message varchar(50) NOT NULL
all primary key id's are unique id's.
all data are linked to http://domain.com/{primary_key_id}
after user visit the link with id, which is unique for all tables.
how should i implement to find what table this id belongs to?
solution 1
select user_id from user where user_id = {primary_key_id}
// if not found, then move next
select photo_id from photo where photo_id = {primary_key_id}
... continue on, until we find which table this primary key belongs to.
solution 2
create object table to hold all the uniqe id and there data type
create trigger on all the tables for AFTER INSERT, to create row in object table with its data type, which was inserted to a selected table
when required, then do select statement to find the table name the id belongs to.
second solution will be double insert. 1 insert for row to actual table with complete data and 2 insert for inserting unique id and table name in object table, which we created on step 1.
select type from object_table where id = {primary_key_id}
solution 3
prepend table name + id = encode into new unique integer - using php
decode id and get the original id with table name (even if its just as number type)
i don't know how to implement this in php, but this solution sounds better!? what are your suggestion?
I don't know what you mean by Facebook reference in the comments but I'll explain my comment a little further.
You don't need unique ID's across five DB tables, just one per table. You have couple of options how to create your links (you can create the links yourself can you?):
using GET variables: http://domain.com/page.html?pk={id}&table={table}
using plain URL: http://domain.com/{id}{table}
Depending on the syntax of the link you choose the function to parse it. You can for example use one or both of the following:
http://php.net/manual/en/function.explode.php
http://www.php.net/manual/en/function.parse-url.php
When you get the simple model working you may add encoding/decoding/hashing functions. But do you really need them? And in what level? (I have no experience in that area so I'll shut up now.)
Is it actually important to maintain uniqueness across tables?
If no, just implement the solution 3 if you can (e.g. using URL encoding).
If yes, you'll need the "parent" table in any case, so the DBMS can enforce the uniqueness.
You can still try to implement the solution 3 on top of that,
or add a type discriminator1 there and you'll be able to (quickly) know which table is referenced for any given ID.
1 Take a look at the lower part of this answer. This is in fact a form of inheritance.
I'm having a hard time representing the following situation in the database:
A user can declare multiple addresses (such as Home, Office, Mailing etc. as requested by client).
I have an auto-incremented primary key called UserID that represents one user account. I've been thinking of making a BelongsToUserID column to represent each user's form field to look like:
I can't do this because each row can only be occupied by UserID row.
Any thoughts on how to achieve this?
You want a separate table holding the addresses. Perhaps something like:
| id(primary key) | type(enum home/work/etc.) | userID | address |
you can make this in two ways
first one is simple but not adviced is that you don't make any primary key and use composite key pair as the candidate key and choose primary from that. as the table is missing the primary key its not adviced
second approach is good and i also use that is to make a master table and use that as the relation-table there and use another table to actually store the data.
in master table you can have id, userid, address_bit, and in second table you can have id, address_bit, address.
please tell me any other solution if you found one. It might help me to learn new :)
I have a website that allows users to be different types. Each of these types can do specific things. I am asking if I should set up 1 table for ALL my users and store the types in an enum, or should I make different tables for each type. Now, if the only thing different was the type it would be easy for me to choose only using one table. However, here's a scenario.
The 4 users are A, B, C, D.
User A has data for:
name
email
User B has data for:
name
email
phone
User C has data for:
name
email
phone
about
User D has data for:
name
email
phone
about
address
If I were to create a single table, should I just leave different fields null for the different users? Or should I create a whole separate table for each user?
Much better if you could create a single table for all of them. Though some fileds are nullable. And add an extra column (enum) for each type of users. If you keep your current design, you will have to use some joins and unions for the records. (which adds extra overhead on the server)
CREATE TABLE users
(
ID INT,
name VARCHAR(50),
email VARCHAR(50),
phone VARCHAR(50),
about VARCHAR(50),
address VARCHAR(50),
userType ENUM() -- put types of user here
)
Another suggested design is to create two tables, one for user and the other one is for the types. The main advantage here is whenever you have another type of user, you don't have to alter the table but by adding only extra record on the user type table which will then be referenced by the users table.
CREATE TABLE UserType
(
ID INT PRIMARY KEY,
name VARCHAR(50)
)
CREATE TABLE users
(
ID INT,
name VARCHAR(50),
email VARCHAR(50),
phone VARCHAR(50),
about VARCHAR(50),
address VARCHAR(50),
TypeID INT,
CONSTRAINT rf_fk FOREIGN KEY (TypeID) REFERENCES UserType(ID)
)
Basic database design principals suggest one table for the common elements and additional tables, JOINed back to the base table, for the attributes that are unique to each type of user.
Your example suggests one and only one additional field per user-type in a straightforward inheritance hierarchy. Is that really what the data looks like, or did you simply for the example? If that's a true representation of your requirements, I might be tempted (for expedience) to use a single table. But if the real requirements are more complex, I'd bite the bullet and do it "correctly".
Try creating four tables:
Table 1: Name, email
Table 2: Name, phone
Table 3: Name, about
Table 4: Name, address
Name is your primary key on all four tables. There are no nulls in the database. You're not storing an enumerated type but derive the type from table joins:
To find all User A select all records in table 1 not in table 2
To find all User B select all records in table 2 not in table 3
To find all User C select all records in table 3 not in table 4
To find all User D select all records in table 4
You should not create tables for different people because this will lead to a bloated database. It's best to create a single table with all the fields you need. If you don't use the field, pass in null values.
I would suggest that you use 1 single table with nullable fields. And a table of something like roles.