This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I have a database design problem. I do not know whether to create two or three tables. the problem is: A terminal has one or zero placements a placement is located in a single location but a location has many placements for example Terminal A (with serial number, manufacturer number etc..) is placed on first floor (placememt) located at loaction X(venue (ex:submay),street,province, city etc.) Terminal B (with serial number, manufacturer number etc..) is placed on second floor (placememt) located at loaction X(venue (ex:submay),street,province, city etc.) Do I have to make a seperate table for terminal, placement,location or put the placement into terminal table, or put the placement into location table as placementt is only a single column.
My team leader has told me to put the placement in location table. But if i do in his way, when I want to edit a location I have to run through all the rows that matches the location which I have to access the table using other columns instead of the primary key (as I use hibernate).Which way is it better to design the database
Sounds like 3 tables to me, and also that your team leader is just not that fond of normalization! If he wants to combine placement with location, what happens if you have a location with no current placements? and what happens if perhaps later another table wants to refer to a location rather than a specific placement at that location? My advice is to create three tables and quickly define a view for the join Placement:Location, and show your term leader that join quickly so that he thinks it's a table!
There is no emoticon for what I am feeling!
Joined: Oct 11, 2005
Thanks Jeff. I mentioned the problem before you told me. He says that adding one more table (only with one column)is more costly than redundant data. Somehow with the help of other team leaders (as the table may require additional fields in the future)I convinced him.