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 database design issue and I'm not sure which of my alternatives I should go with.
I have a system that shows a politician's votes on every issue. Users can log in and "support" that politician on each issue. I'm not sure how the associations should work. Here is a picture of two alternatives:
http://i1068.photobucket.com/albums/u447/dmoss18/ScreenShot2012-05-03at111656AM.png
Option 1: A politician has many votes on many issues. A user supports each politician's vote.
Option 2: A user supports a politician on a certain issue (an association table with three foreign keys).
Is option 2 not feasible at all? Is it bad practice to associate three tables in one entity? Which option is considered best practice?
I would prefer option (1) because it shows that the user supports the particular vote. In option (2) it would seem to be possible (without additional constraints) for a user to support a certain politician on a certain issue when that polititian has never voted on it at all! (Of course if that is a desirable possibility then you must go for option (2)).
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed yesterday.
Improve this question
In all the projects I have worked on, every table in a relational database had as its primary key an auto generated index--an integer that is automatically incremented for each new row. Why?
Plus, no foreign key constraints were present. The relationships among tables were faked.
The "senior" developers working alongside me were not able to give me a proper explanation and all they were able to come with were general answers like "Because it is better this way" or "Because it was done this way".
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 3 years ago.
Improve this question
I created 2 database designs (External & Internal Database). But I'm not sure if that fits in terms of relationship, normalization, logic, redundancy, ....
I also created 2 versions of the database design (The first one without mapping table and the second with). It's in German, I hope that's okay for you.
Do these designs meet typical relational database criteria such as 3NF, and do they specify the entity relationships in a clear and maintainable fashion?
database design 1
database design 2
Edit:
current database design
The ER diagram is OK of both internal and external because it is normalized, no redundancy, no many to many relationships and there is no functional dependency between fields except on the key.
I have a couple of comments about the diagram linked as "current database design":
The BM_Mapping table should use M-ID as its foreign key rather than Meeting_ID. The current design prevents any change to a value in the column Meeting.Meeting_ID.
I would keep the same primary-key naming convention in the Visitor table as used in the other tables. So V-ID rather than Visitor_ID
Apart from these comments, the rest of the design meets the standard RDBMS 3NF and entity relationship standards.
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 years ago.
Improve this question
Often we come across some small insignificant (debatable) tables left out as stand alone. Although they are used in joins (sparingly) but still developers don't bother to relate them.
May be too many References made the inserts slow.
This leads to this question :
As a thumb rule should we relate all the tables in the database ? If no then where to draw the line?
thanks
Foreign Keys are not always a negative impact to performance, they can be a positive impact as well. Database relationships do more than just ensure referential integrity, they also help teach SQL Server about the nature of your data. The fact that two fields are related can give clues as to the cardinality of your queries and thus the optimizer actually takes these relationships into consideration when it's estimating the cost of your query.
In my opinion, if two fields are related in your database, they should have a defined relationship. In general, the more you can teach SQL Server about your data (not just relationships, but CHECK constraints as well), the better it will be at generating efficient query plans. Of course like anything in SQL Server, there are exceptions to the rule, but if you want a rule of thumb, I would lean toward defining all the relationships.
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 8 years ago.
Improve this question
How I can come up with an effective BodyBuilding database, what entities are most important?
From which I should be able to come up with an ER diagram. I'm still a novice to databases, but I have read quite enough, most difficult I'm finding a problem with differentiating between a Gym database and BodyBuilding Club database.
Have you tried listing everything you think relates to the database, then removing the ones you don't like, then grouping them in a way that makes sense to you or users of the database?
Certification types, access to bodybuilding books, bodybuilding trainers, ease of super sets, free weight ratios, ratings from heavy lifters, etc.
Try everything, make a list, narrow it down to the items needed for proper function and your business perspective (safety, legal, etc).
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
When relations between tables are created it becomes very difficult to edit tables, drop and re-create them. well I decide to leave creating relations for when the job is done and that time its not easy either and later some tables might need modifying again.
what is the best practice for creating foreign keys, and all other relations?
In big projects that I devide project to several small projects, well sometime in one of the smaller projects I see that I have to make a small change to previous small projects. and this ruins everything.
I always create relations when I create my initial database structure, and because it is normally (sometimes... once was...) designed properly, the relations don't tend to change.
What you may find eases any changes to the tables is to change one of the options
In Tools-Options, choose Designers - Table and Database Designers and clear the checkbox marked Prevent saving changes that require table re-creation