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 7 months ago.
Improve this question
I'm looking for a little database design advice...
I have a spreadsheet with a few columns in it. Column 1 being a list of categories and the rest being related categories(to the category in column 1). I'm trying to figure out what the best way to setup the tables would be... My thought so far is to have a table that just lists the categories then have a table with 2 columns that holds the id of the category and the id of a related category.... Would this be the best way to do this? Any better ideas?
A self referencing table (parentId to childId) is how most people implement a hierarchical structure like the one you are describing.
Your way is the best. Academics would call it resolving a reflexive many-to-many relationship with an associative entity, but it's nothing more than what you described.
m:n relations should always (maybe there are exceptions) be made with extra table for relations. So it should be the most flexible solution
Related
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 2 years ago.
Improve this question
I am on a project to create a new Java EE application (JSF, Hibernate, Spring Security, Informix database). This application will automate the entry of notes for the annual interview of bank employees.
At the very beginning, everything was entered in an Excel file which then generated a report with the various performance graphs (according to the notes entered from 0 to 4).
Now I want to do a fairly optimized database design. I thought of creating the following tables:
Interview with columns (interview_id, interview_date),
Competency with columns (competency_id, competency_group, competency_name),
Interview_note with columns (interview_note_id, employee_id (FK), interview_id (FK) , competency_id (FK))
However, I have some doubts about how to keep it compact and logical. Is this the right way of doing things? Are there any improvements to take into account for more optimization?
In your narrative and draft database schema, I find the following identified entities: Employee, Competency, Interview and Interview_note.
In this regard, only the Employee table is missing, but I'm sure you have it somewhere. Moreover, your design is very flexible, since it allows for several Interview_notes of the same interview, competence and employee. What is perhaps missing therefore, is the id of who made the notes. Alternatively, if there's only one set of notes for an interview, you could consider to identify the interviewer in Interview.
A part from that, and maybe some missing data for the note (points, percentage of satisfaction, or some textual annotations?) your design seems to fulfil its purposes.
The database engine will very well optimize all the joins you'll have to do. Maybe facilitate its job by defining the _id as primary key, if you didn't do it.
I can't see other optimizations: each table clearly represent a different relation (in the relational algebra meaning of the term) and merging any of them would inevitably result in a suboptimal redundant schema.
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 8 years ago.
Improve this question
I have a couple of properties in my sql server SLS.Customer table which are references to other tables. I can't think of proper names for those tables. Help please :)
Table1: Contains the "How did you hear about us" values. (Example records: Through a friend, Advertisement, Seminar x, conference y, etc.)
Table2: Contains various reasons a customer refused to buy our product.
Table3: Contains the industry/business type a customer belongs to. (I thought of CustomerIndustry or just Industry but it sounds strange!!
Table4: Contains contact info of the person(s) related to a customer entity (specially if the customer is a company, rather than an individual, I need contact info of a person in charge). This is different from the tables PartyAddress and PartyPhones
As the question is suggestion based. I just put some suggestions here.
Table1:
RefererInfo
RefererDetails
Table2:
backlogReasons
backlogInfo
backlogDetails
Table3:
CustomerCategory
CustomerBackground
Table5:
PersonInChargeForParty
ContactsForParty
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 8 years ago.
Improve this question
I have the following entities in my system: COMPANY, POSITION, APPLICANTS. There is many to many relationships between POSITION and APPLICANTS, but the current model does not show that there is many to many relationships between COMPANY and APPLICANTS.
Does it make sense to you to have a join table foo that has the company_id, position_id and applicant_id or i should have a table that joins COMPANY and POSITION and another that joins POSITION and APPLICANTS?
I don't think so. You can get APPLICANT for a given COMPANY via JOIN with POSITION.
I think a relationship between a COMPANY and an individual becomes significant when they shift from APPLICANT to EMPLOYEE. I would not model it as you propose.
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 4 years ago.
Improve this question
I have 2 tables User and User_Event
User
id PK BIGINT
User_Event
event_id PK BIGINT
user_id FK References User.id
Should I create above tables before runtime
OR
should I create table "User_Event" for each Existing user at runtime (In this case table name would be like this
User_Event_user001,User_Event_user002....)
Now my questions is
1. Which design is better?
2. which implementation is faster?
For both questions, the best answer is to have an invariant database structure.
Modifying/creating the tables is a lot of work for databases, as they are designed for managing DATA inside the defined structures (tables, views).
It is very rare that changing the structure on the fly is pertinent, and even less effective.
--> create tables before runtime !
I don't know what is purpose of your system but classical implementation is to have one table User_Event and store data about all users in this table. If you want to get info for one user you should use query:
SELECT event_id FROM User_Event where user_id=<your user_id>;
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 4 years ago.
Improve this question
I am working with system like CMS that need to versioning documents.
what is best practice and methodology for create database for it with any how its table?
I would look first at how MediaWiki did it in their open source project that runs Wikipedia. They're all about versioning.
I prefer to store the new (the new revision) the same way as the posts when they are added the first time, but I have a column called "childOf" which stores the ID of parent post, the the query looks something like:
SELECT * FROM posts WHERE condition=value ORDER BY childOf DESC;
When I did this once I found it worked well to have a table structure like:
tbl.posts
postid(PK) | title | category
tbl.revisions
revisionid(PK) | postid(FK) | authorid(FK) | content | date
Fields that could be changed should go into the revisions table (e.g. content), things that won't go in the posts table (postid, category etc.).
From what I heard on the last podcast StackOverflow does something similar.
In my experience is better to have two different tables one with the data that doesn't need to be versioned, and another one with the data which needs to be versioned (as Spikolynn said in his/her previous answer).
The issue I've found when using only one table is that if other table has a foreign key pointing to that versioned table, as the primary key changes everytime the record is updated the reference is lost. This leads to very complex and inefficient queries in order to recover de data.
Chukc, what you could do to fix that problem is by adding an extra field and use that as the foreignKey
Let's say you have posts:
id, revision, name, content
Revision would be:
id-publish or id-draft or id-revision-N
you then link your other table to revision id-publish instead of id. Just remember to index it :)