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
I have the following question regarding the SQL server 2008 naming standards.
Should I name a table as singular “Customer” OR “Customers”.
If inside the above table I have an ID column; should I name it “CustomerID”, “Customer_ID”, OR “ID” .
Thanks
I use this notation:
L_TABLE for lookup tables, F_TABLE for fact table.
Plural name if a single row describes, for example, a CUSTOMER. The table contains in fact multiple rows (CUSTOMERS) so it will be meaningful.
Descriptor prefix is useful for join and for readability: if you're not the only one to access to that table it's easier to understand if user query will retrieve CUSTOMER_ID, generic ID, ROW_ID and so on. Think about multiple IDs in the same table referring to different fields (even in other tables).
Personal point: for an ID in a look up table I will always use L_CUSTOMER_ID, it's quite long but totally clear.
Use plural, "Customers", the table will hold many rows.
Use just "ID", its easier to always use the same and easier when writing queries. ("select x where Customers.ID = 5")
On a side note, for other tables referencing the Customers table I would name the referencing column to something that describes the relation. Not just "CustomerID" but "PlacedBy_CustomerID" in the orders table, or "PaidBy_CustomerID" in the invoice table. That way the meaning of the relation becomes a bit more present.
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 have an EER diagram of the hospital database. I am currently working on the normalization process.
As I understand the partial dependency is when an attribute is dependent on only the part of the composite primary key. And this should be removed.
I've applied the rules on my database but still want to make sure that these tables doesn't include partial dependency.
In examinationo table the composite key consists of inpatient_no, doct_no and lab_no. In my opinion diagnosis and conducted_test attributes depend on all three of them. Is this correct?
This table has composite key of inpatient_no, doct_no and surgery_no. The attributes date and time convey information when the inpatient will undergo the surgery. Is this a partial dependncy?
I'm very new to databases, so my quesitions can be quite easy.
It looks to me like your table called inpatient_undergoes_surgery represents an entity, in this case an event. The table has one row for each surgical appointment. It has date and time as attributes. It also has one-to-one relationships to an inpatient, doctor, and surgery.
This table appears to be normalized to me. The others might not be. In particular, it's possible that your surgery table duplicates the information in this table.
Pro tip It's best to use a DATETIME or TIMESTAMP data type to represent the kind of date and time in your table. There's no need to use separate columns for date and time. Understanding that the date and time taken together are actually a single attribute of your entity helps clarify your design process.
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 7 years ago.
Improve this question
I have two tables that should somehow be associated. Let's call them table_a and
table_b. A row in table_a can be associated with multiple rows in table_b, and the same goes the other way around. How could I achieve this? Should I use a pivot table?
Both tables have an auto-incrementing id-column.
What you're looking for is called a many-to-many relationship (a given user has zero or more games, a given game has zero or more users). This is typically handled with a "mapping table", e.g. USER_GAMES which has a user_id and a game_id, uniqueness is on the combination of these. http://www.joinfu.com/2005/12/managing-many-to-many-relationships-in-mysql-part-1/ has some good details.
As it is a many to many relationship, an intersection table with the user ID & game ID would be the best. Otherwise you would have to parse the list of game ID's stored in the user table and that would cause performance issues.
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
I'm currently trying to build a football database in MySQL. It should store the fixtures from different leagues, plus their results, odds and some other information.
Is the scheme I just created correct or are there any mistakes in it? If so, what can I improve? I'm also not really sure about the link between tblMatch and tblTeams.
Afterwards I want to be able to make a Query where I can select a fixture including the points the home and away team got before the match, plus the average amount of goals of the teams. Like the new fields: 'homeTeamPoints', 'awayTeamPoints' ect.
So my question is: Where should I put these fields? In an extra table or should I put those in the table: 'tblMatch' and store the precalculated values there?
I hope you get what I tried to explain.
Best Regards
-bababow
A few notes:
You will want to replace "homeTeam" and "awayTeam" with "homeTeamID" and "awayTeamId" which will be foreign keys to the tblTeams table. This will enforce that the teams in the match both actually exist.
Remove the matchID and competitionID from the teams. I'm assuming teams can participate in many matches and competitions and therefore this structure will not support that.
What do you want to know about competitions? Is this a tournament? You may want to have a "bracket" and/or "tournament winner" column in there to store the results of the overall tournament.
Those are my main thoughts, other than that it looks OK.
In my perspective if the values of both the fields needs update regularly and table tblMatch data size is large then you should take it into separate table. if both the fields are updates whenever whole record is change then it could be in tblMatch table.
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 table that will hold 'game stats'. The name of the stats that are held are going to be changing depending on which sport the stats are for.
Is best practice to make two tables: one for the stats with columns such as 'Stat1, Stat2' etc. and another one holding the titles with the sportID as a key. Or would the best practise to have several tables for resorts for each sport. Or any other way?
Thanks,
I agree with andy. A generic-titled column like Stat1 - where the purpose is unspecified in the column name, is used polymorphically, or the column type must be made more generic - usually indicates a poor SQL/RA design.
Consider if this were encountered: create table people (field1 varchar(20), field2 varchar(20)). Yeah - not going to fly in my database. Give the columns (and tables) names that mean something in relation to purpose.
Instead, each different type of information collected should have it's own entity (read: table) or group of related entities. In this case I would imagine that each sport represents a different type of collected stats/information. (Even Win/Loss information can vary by sport.)
Trying to "label" columns based on an additional table is a half-way attempt of an Entity-Attribute-Value (EAV) model. While an EAV can be useful it comes with a lot of downsides in SQL and should not be used except after very careful consideration for a specific use-case. (I do not believe that EAV fits this scenario appropriately.)
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 9 years ago.
Improve this question
Our code is using create/drop table, while generating VR4 queue orders in our database.
When number of websites is less than 250, code is using IN operator and generating reports. ce.website_id in (" . (join ",", #{$website_id}) . ")
When we have more than 250 websites, our code is creating tables (name like Temp_tablename) and using table joining instead of IN operator. Can I replace this code to use IN operator as well? Will there be any performance issue, if IN operator is used with more input values?
As mentioned by Stan, using a temporary table rather than a large IN is the preferred way to go.
When MySQL gets a large data block from the user it stores it in a temporary table and uses a JOIN to look through it. This is easier for MySQL to do than to actually look for each of your values in the IN SQL part.
You can skip this temporary table, by first storing in a table your web site list:
REPLACE INTO tblWebSitesToHandle
(Session_ID, WebSite)
VALUES
('**unique_number**', '**website_id**'),
('**unique_number**', '**website_id**'), ...
Where unique_number will be some number you chose, and then toss away once the query ends - but it will help you manage the list of websites to handle for your query
Then in your SQL that you are currently using instead of IN (...) you will do a JOIN to this table and select from it the relevant Session_ID record.
After that is done, just remove from tblWebSitesToHandle the Session_ID data, it is no longer needed (I believe).