I need to implement a tagging system which is something like this :-
Every user can be tagged on the basis of his education. ( Tags be : Primary, secondary, High School) and these Tags fall under the umbrella of "education".Similarly the user may also be tagged on his interest(Cricket, Football, Rock music, pop music...) Cricket and football come under "Sports", rock music and pop music come under "Music".
Current design is :
User Userid TagID TagName UserId TagID
=========== ============= ============
1 User1 1 Pop 1 1
2 user2 2 Rock 1 2
3 Techno 1 5
4 Cricket 1 6
5 Football 2 1
6 Primary Scl. 2 4
7 Secondary scl 2 7
These 3 form the major tables that allow many to many relationship between users and tags.
secondary tables are:
(Music) (Sports) (Education)
TagID MusicID MusicType TagID SportID Sport TagID EducationID Education
======================= ==================== ============================
1 1 Pop Music 4 1 Cricket 6 1 Primary
2 2 Rock Music 5 2 Football 7 2 Secondary
3 3 Techno Music
the problem in this structure is that a TagID from table TagTable can be referenced by both Music and Sports if care is not taken.There is a chance that pop music and cricket will refer to the same TagID if the developer doesn't take necessary care.
How do I avoid this possibility of multiple referencing ?
Note : The secondary tables have been used to check if the tags fall under the same umbrella. This is feature of grouping tags is necessary.
Looks like you need something similar to this:
NOTE: Tag names are globally unique in the model above. If you need to make them unique per category, just include TAG_CATEGORY_ID in the UNIQUE constraint TAG.U1.
BTW, do you need to limit user to only one tag from certain categories? For example, can user have both Primary and Secondary tags from the Education category, or not? If you need to limit this, you'll need to reference such tags in a different way (as opposed to the "simple" junction table USER_TAG) and there will be certain complications to prevent mixing "single" and "multi" tags...
Related
I'm developing a web application about TV shows. And i need help with the database design.
I made a list of what i need, but i can't figure out how to design it. I have the basic tables. Series, episodes, seasons etc. What i can't do is how to relate people with episodes/series. Here is my list:
There should be multiple people type. Actor/director/writer/guest etc.
I don't think creating seperate table for each type is a good idea. So there should be one people table. And i need to store the type somewhere.
A person may be in 1 or many series.
This can be done with people_serie table with foreign keys to people and series tables. But i need a way to relate a person to episodes too.
An actor may play 1 or many roles.
This can be done with person_role table.
This is where its getting complicating.
A role may be in 1 or many episodes in a serie.
A person may belong to more than one type in a serie. Ex: actor AND director
I hope i make it clear what the problem is.
Well, you're correct not to split the People table.
the first thing to do is add a Roles table, that will contain role id and role title (each column should be unique - you don't want 2 different ids for the Actor role...)
TblRoles
RoleId RoleTitle
-------------------
1 Director
2 Writer
3 Actor
Then you add a PersonToSeries table, that will hold it's own id, the person's id and the series's id.
This table will hold every person ever working on that series, being a regular staff member or a 1 episode guest.
TblPersonToSeries
PTSId PersonId SeriesId
---------------------------
1 1 1
2 3 8
3 4 7
The next table you will need is a PersonToEpisode table, that will hold the PersonToSeries id and the episode id, and the role id.
In this table you only need to keep integer ids so it's very light weight, and you will specify for each record in PersonToSeries the episodes it is relevant for.
TblPersonToEpisode
PTEPTSId RoleId
-------------------
1 2
2 3
3 1
When a person is usually the director of a series, but makes a guess appearance in an episode of that series, you can simply add 2 rows in PersonToEpisode for that PersonToEpisode with a different role id. (one for Actor and one for Director)
TblPersonToEpisode
PTEPTSId RoleId
-------------------
13 1
13 2
I have to create a DB for a game and for the active games I need to save 2 user id's from the users table.
Normally I would use the field user_id in my activegames table to have the reference, but how do I do this with 2 users the same time?
Like user_id1 and user_id2?
Keeping the CakePHP database structure along the convention?
Same question regarding the selected weapons for an active game. Just one would be weapon_id but the player can select up to 4 of them?
weapon_id1, weapon_id2, weapon_id3, weapon_id4?
What is here best practice?
I look forward to your answers!
Kind regards!
You are thinking in 1-1 relations. Try 1-n relations. A "link" table that contains two columns. First is game_id, second is player_id.
This table can have any number of rows for one game. Thus no specific number of players.
player table
id name
1 John Doe
2 jane Doe
game table
id title
1 A special game
game_players relation table
game_id player_id
1 1
1 2
You can do the same with weapons (or anything else)
QUESTION: Is it okay to have "shortcut" identifiers in a table so that I don't have to do a long string of joins to get the information I need?
To understand what I'm talking about, I'm going to have to lay ouf an example here that looks pretty complicated but I've simplified the problem quite a bit here, and it should be easily understood (I hope).
The basic setup: A "company" can be an "affiliate", a "client" or both. Each "company" can have multiple "contacts", some of which can be "users" with log in privileges.
`Company` table
----------------------------------------------
ID Company_Name Address
-- ----------------------- -----------------
1 Acme, Inc. 101 Sierra Vista
2 Spacely Space Sprockets East Mars Colony
3 Cogswell Cogs West Mars Colony
4 Stark Industries Los Angeles, CA
We have four companies in our database.
`Affiliates` table
---------------------
ID Company_ID Price Sales
-- ---------- ----- -----
1 1 50 456
2 4 50 222
3 1 75 14
Each company can have multiple affiliate id's so that they can represent the products at different pricing levels to different markets.
Two of our companies are affiliates (Acme, Inc. and Stark Industries), and Acme has two affiliate ID's
`Clients` table
--------------------------------------
ID Company_ID Referring_affiliate_id
-- ---------- ----------------------
1 2 1
2 3 1
3 4 3
Each company can only be a client once.
Three of our companies are clients (Spacely Space Sprockets, Cogswell Cogs, and Stark Industries, who is also an affiliate)
In all three cases, they were referred to us by Acme, Inc., using one of their two affiliate ID's
`Contacts` table
-----------------------------------------
ID Name Email
-- -------------- ---------------------
1 Wylie Coyote wcoyote#acme.com
2 Cosmo Spacely boss#spacely.com
3 H. G. Cogswell ceo#cogs.com
4 Tony Stark tony#stark.com
5 Homer Simpson simpson#burnscorp.com
Each company has at least one contact, but in this table, there is no indication of which company each contact works for, and there's also an extra contact (#5). We'll get to that in a moment.
Each of these contacts may or may not have a login account on the system.
`Contacts_type` table
--------------------------------------
contact_id company_id contact_type
---------- ---------- --------------
1 1 Administrative
2 2 Administrative
3 3 Administrative
4 4 Administrative
5 1 Technical
4 2 Technical
Associates a contact with one or more companies.
Each contact is associated with a company, and in addition, contact 5 (Homer Simpson) is a technical contact for Acme, Inc, and contact 4 (Tony Stark) is a both an administrative contact for company 4 (Stark Industries) and a technical contact for company 3 (Cogswell Cogs)
`Users` table
-------------------------------------------------------------------------------------
ID contact_id company_id client_id affiliate_id user_id password access_level
-- ---------- ---------- --------- ------------ -------- -------- ------------
1 1 1 1 1 wylie A03BA951 2
2 2 2 2 NULL cosmo BF16DA77 3
3 3 3 3 NULL cogswell 39F56ACD 3
4 4 4 4 2 ironman DFA9301A 2
The users table is essentially a list of contacts that are allowed to login to the system.
Zero or one user per contact; one contact per user.
Contact 1 (Wylie Coyote) works for company 1 (Acme) and is a customer (1) and also an affiliate (1)
Contact 2 (Cosmo Spacely) works for company 2 (Spacely Space Sprockets) and is a customer (2) but not an affiliate
etc...
NOW finally onto the problem, if there is one...
Do I have a circular reference via the client_id and affiliate_id columns in the Users table? Is this a bad thing? I'm having a hard time wrapping my head around this.
When someone logs in, it checks their credentials against the users table and uses users.contact_id, users.client_id, and users.affiliate_id to do a quick look up rather than having to join together a string of tables to find out the same information. But this causes duplication of data.
Without client_id in the users table, I would have to find the following information out like this:
affiliate_id: join `users`.`contact_id` to `contacts_types`.`company_id` to `affiliates`.`company_id`
client_id: join `users`.`contact_id` to `contacts_types`.`company_id` to `clients`.`company_id`
company_id: join `users`.`contact_id` to `contacts_types`.`company_id` to `company`.`company_id`
user's name: join `users`.`contact_id` to `contacts_types`.`contact_id` to `contacts`.`contact_id` > `name`
In each case, I wouldn't necessarily know if the user even has an entry in the affiliate table or the clients table, because they likely have an entry in only one of those tables and not both.
Is it better to do these kinds of joins and thread through multiple tables to get the information I want, or is it better to have a "shortcut" field to get me the information I want?
I have a feeling that over all, this is overly complicated in some way, but I don't see how.
I'm using MySQL.
it's better to do the joins. you should only be denormalizing your data when you have timed evidence of a slow response.
having said that, there are various ways to reduce the amount of typing:
use "as" to give shorter names to your fields
create views. these are "virtual tables" that already have your standard joins built-in, so that you don't have to repeat that stuff every time.
use "with" in sql. this lets you define something like a view within a single query.
it's possible mysql doesn't support all the above - you'll need to check the docs [update: ok, recent mysql seems to support views, but not "with". so you can add views to do the work of affiliate_id, client_id etc and treat them just like tables in your queries, but keeping the underlying data nicely organised.]
I have a table User that stores user information - such as name, date of birth, locations, etc.
I have also created a link table called User_Options - for the purpose of storing multi-value attributes - this basically stores the checkbox selections.
I have a front-end form for the user to fill in and create their user profile. Here are the tables I have created to generate the checkbox options:
Table User_Attributes
=====================
id attribute_name
---------------------
1 Hobbies
2 Music
Table User_Attribute_Options
======================================
id user_attribute_id option_name
--------------------------------------
1 1 Reading
2 1 Sports
3 1 Travelling
4 2 Rock
5 2 Pop
6 2 Dance
So, on the front-end form there are two sets of checkbox options - one set for Hobbies and one set for Music.
And here are the User tables:
Table User
========================
id name age
------------------------
1 John 25
2 Mark 32
Table User_Options
==================================================
id user_id user_attribute_id value
--------------------------------------------------
1 1 1 1
2 1 1 2
3 1 2 4
4 1 2 5
5 2 1 2
6 2 2 4
(in the above table 'user_attribute_id' is the ID of the parent attribute and 'value' is the ID of the attribute option).
So I'm not sure that I've done all this correctly, or efficiently. I know there is a method of storing hierarchical data in the same table but I prefer to keep things separate.
My main concern is with the User_Options table - the idea behind this is that there only needs to be one link table that stores multi-value attributes, rather than have a table for each and every multi-value attribute.
The only thing I can see that I'd change is that in the association table, User_Options, you have an id that doesn't seem to serve a purpose. The primary key for that table would be all three columns, and I don't think you'd be referring to the options a user has by an id--you'd be getting them by user_id/user_attribute_id. For example, give me all the user options where user is 1 and user attribute id is 2. Having those records uniquely keyed with an additional field seems extraneous.
I think otherwise the general shape of the tables and their relationships looks right to me.
There's nothing wrong with how you've done it.
It's possible to make things more extensible at the price of more linked table references (and in the composition of your queries). It's also possible to make things flatter, and less extensible and flexible, but your queries will be faster.
But, as is usually the case, there's more than one way to do it.
I am considering how to structure my MySQL database in e-commerce solution. To be more specific I am looking at the product structure.
These are the tables I have come up with so far. What do you think?
Explanation of structure
The application is multilingual. Therefore the product table are split in 2 tables.
If a products has e.g. 2 variants (Small, Medium) a total of 3 rows will be inserted. This is because each variant can have different information for each variant. When the product is shown on the webpage product 1 will be shown with a drop down box with Small & Medium. A product with no variants will naturally only insert 1 row.
products
id master product_number
1 0 123
2 1 456
3 1 678
products_descriptions
id product_id country_code image name description vat price
1 1 en-us image.jpg t-shirt Nice t-shirt 25 19.99
2 2 en-us image.jpg t-shirt Nice t-shirt 25 19.99
3 3 en-us image.jpg t-shirt Nice t-shirt 25 19.99
products_to_options
product_id option_id
2 1
3 2
options
id name
1 Small
2 Medium
Your Products table is schizophrenic, its entity is sometimes Product and sometimes Variant. This leads to very cumbersome behavior. For example, you'd like the question "how many different products do we have?" be answered by select count(*) from products, but here this gives the wrong answer, to get the correct answer you have to know the Magic Number 0 and query select count (*) from products where master=0. "List all products and how many variants we have for each" is another query that should be straightforward but now isn't. There are other anomalies, like the fact that the first line in products_descriptions is a shirt that has a price and a picture but no size (size is stored in the variants, but they have prices and pictures of their own).
Your problem sounds like you have products in two contexts: (1) something that can be displayed as an item in your store, and (2) something that can be ordered by your customer. (1) probably has a name like "Halloween T-Shirt" or so, and it probably has an image that the customer sees. (2) is what the customer orders, so it has a (1), but also a variant specification like "small" or maybe a color "red". It probably has a price, too, and an order_id so your shop can know what specific item to ship.
You should give each context an entity. Here's how i'd do it
displayable_product
id name
1 "Baseball Cap"
2 "T-Shirt"
orderable_product
id d_product_id order_id size color price
1 1 123 red 9.99
2 2 456 small 19.99
3 2 789 medium 21.99
displayable_content
id d_product_id locale name image
1 1 en_US "Baseball Cap" baseballcap.jpg
2 1 es_US "Gorra de Beisbol" baseballcap.jpg
3 2 en_US "Nice T-Shirt" nicetshirt.jpg
4 2 es_US "Camiseta" nicetshirt.jpg
You should probably use locale instead of country in the display tables to account for countries with more than one language (USA, Switzerland, and others), and you might separate the size and color into its own variants table. And if you need country-dependent data on the orderables (like different prices/currencies for shipping to different countries), you'd have to extract a country-dependent orderable_content table, too.