-1

I had a discussion with a coworker on which would be best for a relational database.

We have a Customer table

Customer ={
   ID,
   Setting1,
   Setting2,
}

And we have a form response Table

FormResponse = {
    ID,
    Q1,
    Q2
}

Both tables need to have a Company attached to them so I suggested a Company table with CompanyID in each table for reuse. Keep in mind this is a 1 to 1 relation because we will always be storing new companies for every form submit. While he suggested we add the Company fields directly to the Tables. I'm more of a programmer OOP suggest we keep the objects separate. Although I do see that we would probably have better performance if we kept it all on one table. Programmatically i think it would be cleaner to keep them separate. What would you suggest?

Answers to comments / explanations:

Is there a relationship between Customers and FormRequests?

There is no direct relation between Customers and FormRequests. Our customer create forms and we keep track of their requests. So the way to relate customers to requests is through the form id.

Edit:

Say you have two tables.

Table1 = [a, b, c, d, e, f, g] 
Table2 = [h, i, j, a, b, c, d]

Each letter being a different attribute. (Attributes being things like name,age,haircolor...) There is no relation between Table1 and Table2. As you may have noticed Table1 has attributes/columns [a,b,c,d] in common with Table2. Provided of course attributes [a,b,c,d] make sense as an object on its own.

Would it be proper relational db design to create a new table (Table3) with attributes [a,b,c,d]? Keeping in mind that it would retain its 1 to 1 relation from Table1 or Table2 to Table3.

If it makes a difference would the number of fields make a difference or perhaps if there was another table with attributes [a,b,c,d,k,l,m,n]?

closed as unclear what you're asking by ypercubeᵀᴹ, Andriy M, paparazzo, MDCCL, Tom V Sep 30 '16 at 18:00

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    "we will always be storing new companies for every form submit." This makes very little sense. – ypercubeᵀᴹ Sep 29 '16 at 22:05
  • @ypercubeᵀᴹ We have no way of vetting that the person is indeed from said company. On top of which we always need the original form post data. Creating a company record and updating the information at any moment would require further tracking for update history. – ozz Sep 30 '16 at 15:15
  • i don't understand the business logic. Seems like this CustomerID is totally useless. – ypercubeᵀᴹ Sep 30 '16 at 15:18
  • 1
    Besides that, the design seems lacking or you have omitted crucial parts. Shouldn't the FormRequest store who made that request (UserId, CustomerId, something)? And are all these the tables you have? Just Customers that make FormRequests? Or are all other tables irrelevant? – ypercubeᵀᴹ Sep 30 '16 at 15:21
  • 1
    You should have a proper details, not randomly thrown names and columns, if you want a decent answer. And I was only asking what is the relationship between Customers and FormRequests. That is relevant. (Tables don't have fields by the way, they have columns.) – ypercubeᵀᴹ Sep 30 '16 at 15:43
0

If you are absolutely sure that you would never ever work with any Company as a separate entity then de-normalisation of "Company" (storing the value(s) directly in Customer table) can be justified. If there is even a tiny chance that in the future you might want to do anything to a Company whatever the Customer(s) are then create a separate Company table now.

  • Sounds like there is no definitive answer if you say it can be justified. Assuming we never work with company as a separate entity, what would you say is the best thing to do? – ozz Sep 30 '16 at 14:35
  • 2
    @ozz I'd say create a company table, because it simply a better, cleaner feeling. – dezso Sep 30 '16 at 16:26
  • @dezso Agreed. Seems more of a preference thing with no definitive answer. Thanks for your answers. As a programmer trying to learn more about the db side of things i really appreciate it. – ozz Sep 30 '16 at 17:03

Not the answer you're looking for? Browse other questions tagged or ask your own question.