I have 2 tables called : PayPeriod and Contractor. I have one process, which will create the bill for contractors. Now I want to track that for one payperiod, for which contractors, bill is created. I want to track this because sometime there may be a case when for some of contractors, bill is not created.
How to track this at database level??? Need suggestion for table structure.
You may create three table as given below to contain this information.
PayPeriod - Contains all bill periods
Contractor - Contains details for contractor
Bills - This table has foreign keys for Contractor and PayPeriod table and bill information.
Related
Recently I'm working on a project, in which I need save multiples subjects in my database, and numbers of subject will be change as per student's class. e.g: class "VII" has 6 subject (included 1 option subject), class "VIII" has 8 subjects (1 included option subject) and so on. Even the option subject can be different according to student's choice.
I'm using CheckedListBox control. Here is a screenshot.
I'm using MS Sql Server 2012. I'm facing difficulty to design database table. I can't understand should i create all the subject columns in my student table or ????(best way). Please help me, thanks in advance.
What you are describing is something that is called a Many to Many relationship. Many Classes have Many students.
You will have a students table, a subjects table and then a table student_subject table which links both the primary keys of the students and subjects table.
Reference: Many to Many
If a Student can have multiple Subjects, and a Subject can have multiple Students, then that's a many-to-many relationship. Which means there would need to be an intermediary table to link them.
Start with the tables for the objects themselves:
Student
----------
ID
Name
etc.
and
Subject
----------
ID
Name
etc.
Since these are independent aggregate root objects in the domain and neither one owns another one, their tables just contain information which describes that object. A Subject, for example, could have a name and a description, maybe a list of pre-requisites, etc.
Then you create the relationship table between them. A common practice is to just combine the names:
StudentSubject
----------
StudentID
SubjectID
If no two pairs of Student and Subject can be repeated, then the two foreign keys together can make the primary key. If they can be repeated (if the same Student can have the same Subject more than once) then you'd probably want to add a separate primary key to the table.
At its simplest, all this table does is create the relationships between the records in the main tables. However, this can potentially grow to be a domain entity in and of itself. If there are any attributes which describe the relationship between a Student and a Subject, those would be added to this table.
Your database schema should look something like this......
Students
Student_ID (PK)
Student_Name
etc .......
Subject
Subject_ID (PK)
Fee
etc......
Student_Subjects
Student_ID FK Students(Student_ID)
Subject_ID FK Subject(Subject_ID)
DateStarted
etc.....
This picture of my tables in the database :
In what fields do I need to make a connection table ?
and user form :
For example, a user form, this figure is almost .
When the user add table name to treeview , questions relating to the same table will appear .
Now may communicate simultaneously with 3 to Table .
Finally, we report user's choices and responses .
And report like this picture :
Thank you my friends
Please tips me for continue working .
I think you need an intermediate table to provide the links:
InquiryID
NodeType (value related to an enum listing Compact, Air, Traditional)
NodeID (this is either CompactID, AirID, or TraditionalID)
//other fields?
This table could provide either 1:1 or 1:many links (duplicate InquiryID related to more than one NodeID).
So records might look like:
1 | 1
1 | 2
2 | 1
3 | 2
Don't worry, is some situations that is normal that you can't create FOREIGN KEY constraint. You just should start distinct situations where DBMS should mange data consistency from the situations where this yours responsibility.
And the case of inquiry / orders - is exactly such situation.
I got site for selling products. In my database I have 3 tables: Users, Countries, Products.
Each user can sale his products in many countries.
When clients come to visit, my site, they can choose to search for product by country and by product price( same product sold by same user can have different prices in each country).
I thought about two implementations for this:
Create a linked table with user_id, country_id, product_id. In this case each time I would like to add new product I will need to update two tables, the linked table and the products table.
Or create new table for each country, that will have products in it. So when I will have to add new product I will only need to update one table.
I like my second solution more, because I think it will perform faster, for both reading and inserting, how ever it's management is hard, I will have lots of tables, and what if instead of counties I would like to use cities, I will get thousandths of tables.
Is there a way in MySQL to create a table of tables?
What do you think about my design will it rarely perform faster?
Do NOT go for the second solution. Relational databases are meant to have a fixed number of tables, and you will run into a lot of problems if you try to have a variable amount of tables in the manner you describe.
If I understood your requirements correctly, you should probably use two linked tables: one that contains user_id and country_id (thus telling where each user may sell products), and one that contains country_id, product_id, and price (thus telling the price of each product in each country). (This assumes that a product costs the same within a country no matter who sells it.)
Just after some advice regarding this database design situation.
So I have two tables in the database.
Table 1: Patients
Table 2: Claimants
Patients holds attributes data on a private patient, so details about the person, his/her birthday, names, medical conditions, etc etc..
Claimants is the entity who pays on behalf of the patient, so Claimant can be a patient himself, another person, a business (who pays for work injury), private healthcare provider, government bodies etc etc..
Patients and claimants have IDs who are foreign keys in other tables such as invoices, receipts etc...
One Patient can have multiple Claimants (More than one entity can pay on his behalf), each Claimant can have multiple patients.
On further investigation, I've identified that many of the attributes of Patients and Claimants overlap as a Patient can pay for himself thus is a private Claimant.
My thinking is to merge the two tables into one and simply call it accounts and have a claimantType field to identify the type of the account, be it private, healthcare, business or government.
What potential practical drawbacks do I need to keep in mind with this change? Apart from the changing the other linked tables in database?
EDIT: Just to make it clear, There's already a junctional table PatientClaimants which basically just map the patients to the claimants. Thanks!
Merging these two tables I believe is wrong.
A patient is always a human. So it cannot be a business or an organisation.
I believe here you have:
Address
=======
......
Person
=======
AddressId (FK)
BusinessEntity
==============
AddressId (FK)
Patient
=======
PersonId (FK)
Claimant
========
PersonId (FK)
BusinessEntityId (FK)
Here PersonId or BusinessId one of them can be null.
You could either (a) put in an intersection table that relates patient IDs to claimant IDs, or (b) as you discussed, merge them together - but if you already have data out there that could be problematic.
You could also set up a demographics table that shows common data between patients and claimants and references an abbreviated patient/claimant table - this way you do not break your existing structure.
If i have bills (from vendors), and invoices (to customers), would it be better to keep them separate (in two tables), or in a single table?
What about vendors / customers?
These are all relational-inheritance problems, can you give me some best practices regarding this?
It seems to me that an incoming bill and an outgoing invoice are really different things:
The outgoing invoice will have line items that match your product table
The incoming bill will have a very formal approval process, involving managers, finance, and accountants
The "From" on an incoming bill is your partner, but on an invoice, the partner's name is the "To"
Entities that are that different should have their own table. If they have common properties, you could store them in a Document table, and create a relation between that table and the Invoice and Bill table.
I would suggest that if they are separate concepts, keep them separate. Usually when you start out designing a database and you have entities that have the same columns in their tables, the urge arises to consolidate them into 1 table. If you know for a fact that for the duration of the solution, you will never need ta add say customer-specific fields or vendor-specific fields, I would say go ahead and make them 1 table.
Keeping them separate allows each entity to develop on its own as the system grows and matures.
A dangerous road for many reasons.
I suppose logically speaking you could collapse everything into one table with a column "PrimaryKey" and optional columns Col1, Col2, Col3, etc. all varchars interpretable to other types.
Especially with financial data where there are audit trail and archiving issues, this is not a simplification.
(But it's the sort of strategy we all go through as a passing phase ...:) )
In our ERP system we have bills and invoices separate; vendors and customer we have in one table.