Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am trying to explain the benefits of a join table to a colleague, and below is an explanation. Am I correct?
Currently he has the relationship between a pic and tag with two tables. A pic table and a tag table. The pic table has a tag_id this is a FK to an entry in the tag table. Here was my response:
First lets look at pics and tags tables. So in your current architecture lets imagine two pics (a & b). We tag pics a & b with the hashtag #wtf. We now have two entries in out tags table:
pic_id title
------ -----
a wtf
b wtf
Do you see the issue? So imagine we have 1000 wtf tags on a 1000 different pics. With this same architecture we now have a bloated tags table with all this repeated data (and wasted space). This issue arises when we have a many to many relationship. In this case many pics can have many tags, and many tags can have many pics. How would we fix this? The answer is a join table. So we create a new table. Lets call it pic_tag. This table would have columns pic_id & tag_id. So now new tables would look like:
pic_tag
pic_id tag_id
------ ------
a 1
b 1
tags
id name
-- ----
1 wtf
pic
id name
-- ----
a pic1
b pic2
So this does a couple of things for us. First it saves space. We only store the string 'wtf' one time. Second, to find all pics with the tag 'wtf' we first go to the tag table and find the id of 'wtf', then go to the pic_tag table and search for that id which is much more efficient that searching a bloated 'tags' table for a given text. Said another way, search for ints is much faster than searching for text.
The main benefit is that there are relationships that can only be modeled with a join table.
Say you have two entities A and B. If the relationship A:B is 1:1, the two can be represented by a single table. If A:B is 1:N (like 1 customer can have N orders but each order comes from only one customer), then you could model this as a foreign key from orders table to customers table. But if A:B is N:M (your tags scenario is a good example) you need a way to represent 0, 1 or N tags for each picture. There is no sound relational representation for that other than a join table.
Note you could represent multiple tags per picture while breaking some principles of relational design (like storing multiple tags or FK's to tags) in a single column. Whether to do that or not is a design decision.
Other benefits: you can change your mind whether the relationship is 0:1, 0:N, 1:(0-5), 1:N etc. without changing the core data model -- addressing that logic in triggers or application logic. You can create additional indexes to help with joins. You can introduce more uniqueness constraints to enforce data logic etc.
But the main benefit is, join tables are the only relationally sound way to model certain types of relationships.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
In large system, when analyzing the database, there are about 50 different categories in the requirements, which should represented as tables.
Each category has many attributes - columns-, all these categories has the same of 50% of columns. For example, each category has (id, name, date, state, admin, dept), all categories have those attributes, but each category has its own attributes which differ from each other, they are about 3 - 5 attributes.
Now, how to represent them in the physical database as tables? One table, or table for each category, what about redundancy?
Depends on what exactly you are trying to achieve.
If your primary concern is disk space, I would recommend to consider sparse columns, with column sets as an option, if necessary. In this scenario, you can put all these entities into a single physical table, with mandatory attributes being normal columns and specific attributes being declared as sparse.
If you are thinking about a normalised model which would eliminate most of data anomalies, a typical solution is a supertype-subtype hierarchy. The main table stores only the attributes that are mandatory for all entities, and child tables contain only main table' identifier and attributes specific to this particular category. All the child tables reference the "supertype" table via foreign keys.
Sometimes, depending on subject area, a more complex model with additional "nesting" levels might be employed. You can think of this as a class inheritance hierarchy - the analogy is very close, actually.
Of course, both (and other) approaches have their strengths and weaknesses, so you might need to read up on the subjects and make a choice.
As some attributes are only applicable to some categories, you can think of Entity-Attribute-Value model, for storing the categories.
There are multiple ways of representing EAV models in a database. You can refer to below article: https://inviqa.com/blog/understanding-eav-data-model-and-when-use-it
The EAV model way of data storage comes up with its own challenges, when you query the database. So, see whether it will suit your needs, before choosing the same.
I am fairly new to SQL queries. I want to display the same product that has been serviced at three different labs or service stations.
I want to list and display the macbook represented by the id at the three different stations (or more) being displayed too.
Ok, so normally on stackoverflow, people tend to show what they tried and why it didn't work. In fact this question will probably be closed as too broad, but I empathize with starting with sql. But I will match the broadness of your question with a broad answer.
You should splt the tables up. I might try to have three tables:
A table describing each product with unique id
A table describing each service location with a unique id
A table describing each transaction with a unique id consisting of product ID and location id
Then when you need the data you would perform a join which would return the table containing the information you want.
I have a simple question here regarding GroceryCRUD.
The question is: Is there a way to build a CRUD using Grocery when I have multiple relationship (JOINs)? For example: I want to have a CRUD for the following:
Table QUESTIONS
IDQuestion
IDRightAnswer
IDKnowledgeArea
Question
IDExplanation
One Record in this table would contain:
IDQuestion IDRightAnswer IDKnowledgeArea Question
10---------------2----------------------3---------------------------What is the color of the sun?
Table KnowledgeArea
ID------------Name
1--------------Phisics
2--------------Math
3--------------Astronomy
So, as this is normalized table, for those IDs (except for IDQuestion cuz it is PK and IDRightAnswer cuz its a FK) which is/are FK in the Questions table, I would like to have the correlated values (text) from Original table displayed in the grid rather than the ID itself.
So, using the same example, for the column IDKnowledgeArea in the table Questions (its a FK here) the CRUD would bring a combobox with the original values (text) in the table IDKnowledgeArea then I could chose it from there.
For example:
IDQuestion IDRightAnswer IDKnowledgeArea Question
10---------------2-----------------------Astronomy-------------What is the color of the sun?
All the CRUD tools I've seen doens't have such resource and although they provide good CRUD approach they never address this multi-relationship between the entities.
I appreciate any answer.
Thank you
Actually I gave a look on the documentation and I found this:
http://www.grocerycrud.com/documentation/options_functions/set_relation
Set a relation 1-n database relation. This will automatically create a dropdown list to the fields and show the actual name of the field and not just a primary key to the list. An example of this:
$crud->set_relation('user_id','users','username');
Thank you all
I'd like to hear opinions on if it is better to keep forum categories and subcategories in the same table or in two separate tables...
Let's say you have a table ForumCategories. By adding a colum ParentId referencing the PK Id in the same table you could easily keep both the main categories and subcategories in the same table.
Alternatively, you could create a separate table ForumSubCategories and make the Id on that table a FK referencing PK Id column of the ForumCategories table.
Both solutions would work but what are the pros and cons of each solution?
Obviously, this is a more generic question that can apply to many other scenarios I just couldn't come up with a better phrasing in a hurry...
I can't think of any benefits of using 2 tables. Using 2 tables is going to constrain you to a 2 level tree. If you look at things as objects, then subcategories really are just category object. So put them in the same table. The 1 table structure will be simpler to design around and develop queries for.
If you know for sure that your forums will have only 2 levels of categories, then having 2 tables is reasonable.
Though storing categories in one table with foreign key to itself, basically, allows you store a tree of categories with virutally unlimited levels.
If they are the same entity (Category), you can link to itself. The parent would have a null for the parent ID or it could be linked to itself. This limits you to only one level unless you have a second table to handle the many-to-many possible relationships.
They must have the same fields or you're going to have unecessary fields for one or the other type. A separate table is why you would do this because they're not the same.
This is typical for an employee table. The supervisor is another employee record.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
What's the correct or most popular name for an "association table"?
I've heard lookup, associative, resolving, mapping and junction table.
There is no "correct" name, but the academic name would be an "Associative Table" (see See the Wikipedia article Associative Entity). Other common names are (in alphabetical order):
Association table
Bridge table
Cross-reference table
Crosswalk
Intermediary table
Intersection table
Join table
Junction table
Link table
Linking table
Many-to-many resolver
Map table
Mapping table
Pivot Table
Pairing table
Relationship table
Transition table
Note: This is contents original created by Derek Greer but that was posted as an edit to an accepted answer that totally changed the answer.
Cross reference table. CustomerProductXRef.
"Correct" depends on the modeling methodology in use. I am familiar with Chen, in which this table is the physical implementation of an Associative Entity. I suppose most popular would be directly related to most popular modeling methodology.
Wikipedia lists several names for this type of table.
I was taught and use the term "Join Table"
Depends on whom you ask. They're all correct, use the term that makes the most sense to who you're talking to.
Relationship table.
"One of the basic tricks in SQL is representing a many-to-many relationship. You create a third table that references the two (or more) tables involved by their primary keys. This third table has quite a few popular names, such as 'junction table' or 'join table,' but I know that it is a relationship."
Hollywood Couples by Joe Celko
Do you call your customer table CustomerTable or Customer or Customers? I generally use a "business object" name (eg Orders for information about which customers have ordered which products, not CustomerProduct) but a table that really just tracks the relationship, like SalesRepCustomer, I give the name of the two tables involved and don't add a suffix. As others say, be consistent.
I reserve the name lookup (in conversation, not in the table name) for things like "what is the name of Country 11", not for "which sales rep looks after Country 11".
We call these Crosswalk tables where I work. Naming is based on Table1XTable2 where the contents are the PKs of the 2 tables.