I m try to make a Table using Create Table in SQL,
where a person can work at multiple places, and a place can have multiple person working on it,
this is what i m trying, i m sure its not correct
create table ( person char(15), place char(15), salary int)
now since a person can work in multiple places, i m confused should the tuple place has multiple values,
if yes. how do i do it
Thanks in advance
It is called a n to m relation. Use 3 tables
persons table
-------------
id int
name varchar
places table
------------
id int
name varchar
place_persons table
-------------------
place_id int
person_id int
You should create three separate tables:
"persons"
int ID (primary key, auto-increment)
varchar username
varchar email ... (all other info needed)
"places"
int ID (primary key, auto-increment)
varchar name
etc.
And the third table gives you the relationship between the two:
"person_places" (or place_persons, depends on what you like)
int ID (primary key, auto-increment)
int place_id (linked to the ID of the "places" entry)
int person_id (linked to the ID of the "persons" entry)
This way, every time a person starts working in a new place, you just add an entry to the "person_places". Same thing when they leave a place, or a place goes out of business or whatever, you just need to touch the "person_places" table.
Also, this way, one person can work in several places, just like one place can have several people working in it.
This is not normalized but it is ok to use this as you have only 3 columns and normalization will add more headache of joins and extra columns to define relationship.
suppose PersonA works in both PlaceA and PlaceB. PersonB also works in both the places but on different salaries then your data will be like this
insert into Yourtable values
('PersonA','PlaceA',1000),
('PersonA','PlaceB',2000),
('PersonB','PlaceA',1100),
('PersonB','PlaceB',1200),
('PersonC','PlaceA',1000)
and if you want to know that how many places PersonA works then you query will be
select place from YourTable where person = 'PersonA'
This way you don't need to save multiple values in same tuple.
Related
For my RSS aggregator, there a four tables that represent rss and atom feeds and, their articles. Each feed type and entry type will have zero or more categories. In the interest of not duplicating data, I'd like to have only one table for categories.
How can I accomplish this?
One way is to keep categories in one single table - e.g. category - and define an X table for each entity/table that needs 0 or more category associations:
rssFeedXCategory
rssFeedId INT FK -> rssFeed (id)
categoryId INT FK -> category (id)
atomFeedXCategory
atomFeedId INT FK -> atomFeed (id)
categoryId INT FK -> category (id)
and so on.
You can define a PK for both columns in each table, but an extra identity column may also be used. When working with an ORM, I also have an extra identity/autoincrement column (e.g. XId INT), so that a single column can be used to identity a row.
Say, we have data of person that have some possessions. The person can have nothing or have anything. What is the proper way to store data like this?
As far as I know, MySQL doesn't provide a way to store array as a data type. If it does, maybe it will be something like this:
CREATE TABLE person (
id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(100) NOT NULL,
possessions ARRAY NOT NULL
);
I believe what you would be looking for is three tables (or two if each possession can only be owned by one person).
Table Person has PersonId (INT PK Identifier) and PersonName (along
with any other person attributes)
Table Possession has PossessionId
(INT PK Identifier) and PossessionName (along with any other
possession attributes)
Table PersonPossession has PersonId and
PossessionId representing that the person has that possession.
This is a fairly simple design for an m:n relationship (i.e. a person has some number (possibly 0) of possessions, and possessions have some number of "owners")
If each possession can only be owned by a single person you can go down to two tables by eliminating table PersonPossession and just having PersonId being a column of the Possessions table
I have two tables:
Friends :
id name
1 jhon
2 peter
Teammates:
id name
3 juan
i am looking for a way two auto increment the id of the second table (teammates) according to the first table ( Friends ).
When I add a new register to Teammates it never match with an id of Friends
I think this is not good practice. If you do so, you are introducing an implicit functional dependency between both tables outside of the declared design. If you want to it anyway, you can use a trigger to asign the value instead of making the column autoincrement.
I would suggest to have a table for all people with the real autoincrement id, then you can use several approaches:
i) Make your two actual tables take id values as foreign keys of this new table, with the corresponding integrity constraint.
ii) Simply create 2 views of the table: One for friends, other for teammates.
Table_Friends: (id, name, role)
View_Friends: Select id, name from table_Friends where role = value_for_friend_role
View_Mates: Select id, name from table_Friends where role = value_for_teammate_role
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.
Ok, so I am going to have at least 2 tables, possibly three.
The data is going to be as follows:
First, a list of search terms. These search terms are unrelated to anything else in the program (only involved in getting the outputs, no manipulation of this data at all), so I plan to store them separately in their own table.
Then things get trickier. I've got a list of words, and each word can be in multiple categories. So for example, if you have "sad", it could be under "angst" and "tragedy", just as "happy" could be under "joy" and "fulfillment".
Would it be better to set up a table where I've got three columns: a UID, a word, and a category, or would it be better to set up two tables: both with UIDs, one with the word, one with the category, and set them up as a foreign key?
The ultimate role is generating number of words in a given category over a given period of time.
I'll be using MySQL and Python (MySQLdb) if that helps anyone.
Ignoring your 'search terms' table (since it doesnt seem to have any relevance to the question), I would probably do it similar to this
words (w_id int, w_word varchar(50))
categories (c_id int, c_category)
wordcategories (wc_wordid int, wc_catid int)
Add foreign key constraints from the ids in wordcategories, onto word and categories tables
Without having a whole lot of details, I would set it up the following way:
Word Table
id int PK
word varchar(20)
Category Table
id int PK
category varchar(20)
Word_Category Table
wordId int PK
categoryId int PK
The third would be the join table between the word and the category. This table would contain the foreign key constraints to the word and category tables.