I'm currently working on a SQL assignment that wants me to:
Add an index for each foreign key and an index on Company for Customer and Shipper.
I've created the 3 tables that were needed, created the foreign and primary keys, and so on. But my textbook has not mentioned anything about indices and I am at a loss as to what to do. If you have an answer, it'd be nice to know how you got to it.
The structure of the tables:
Customer
CustomerID (PK) | Company | ContactName | Phone
Order
OrderID (PK) | OrderDate | ShippedDate | ShipperID | Freight | CustomerID (FK)
Shipper
ShipperID (PK) | Company | Phone
You should be looking at the online documentation, but...
To create indexes for foreign keys:
create index Order_ShipperID on Order(ShipperID);
create index Order_CustomerID on Order(CustomerID);
To create indexes on Company for Customer and Shipper:
create index Customer_Company on Customer(Company);
create index Shipper_Company on Shipper(Company);
The names of the indexes can be anything, but I usually follow this naming convention.
BTW, the choice of name "Order" is a poor one because its a reserved word.
You can create Index on any SQL Table column. Once Indexes are created on your Table column you just have to send the Select query and you can check logically the performance of you query. You can check the next link for reference to the solution:
www.blog.mastersoftwaresolutions.com/how-do-database-indexes-work/
Related
Let's say I have two tables and I'm doing all the operations in .NET Core 2 Web API.
Table A:
Id,
SomeValue,
TeamName
Table B:
Id,
Fk_Id_a (references Id in table A),
OtherValue,
TeamName
I can add and get records from table B indepedently.
But for every record in Table B TeamName has to be the same as for it's corresponidng Fk_Id_a in Table A.
Assume these values comes in:
{
"Fk_Id_a": 3,
"SomeValue": "test val",
"TeamName": "Super team"
}
Which way would be better to check it in terms of performance? 1ST way requires two connections, when 2nd requires storing some extra keys etc.
1ST WAY:
get record from Table A for Fk_Id_a (3),
check if TeamName is the same as in coming request (Super team),
do the rest of the logic
2ND WAY:
using compound foreign keys and indexes:
TableA has alternate unique key (Id, TeamName)
TableB has foreign compound key (Fk_Id_a, TeamName) that references TableA (Id, TeamName)
SQL SCRIPT TO SHOW:
ALTER TABLE Observation
ADD UNIQUE (Id, PowelTeamId)
GO
ALTER TABLE ObservationPicturesId
ADD FOREIGN KEY(ObservationId, PowelTeamId)
REFERENCES Observation(Id, PowelTeamId)
ON DELETE CASCADE
ON UPDATE CASCADE
EDIT: Simple example how the tables might look like. TeamName has to be valid for FK referenced value in Table A.
Table A
ID | ObservationTitle | TeamName
---------------------------------------
1 | Fire damage | CX_team
2 | Water damage | CX_team
3 | Wind damage | Dd_WP3
Table B
ID | PictureId | AddedBy | TeamName | TableA_ID_FK
-----------------------------------------------------
1 | Fire | James | CX_team | 1
2 | Water | Andrew | CX_team | 1
3 | Wind | John | Dd_WP3 | 3
Performance wise, the 2nd option would be faster because there is no comparison to check (the foreign key will force that they match when inserting, updating or deleting) when selecting the rows from the table. It would also make a unique index on table A.
That being said, there is something very fishy about the structure you mention. First of all why is the TeamName repeated in table B? If a row in table B is "valid" only when the TeamName match, then you should enforce that no row should be inserted with a different TeamName, throught the ID foreign key (and not actually storing the TeamName value). If there are records on table B that represent another thing rather than the entity that is linked to table A then you should split it onto another table or just update the foreign key column when the team matches and not always.
The issue is that you are using a foreign key as a partial link, making the relationship valid only when an additional condition is true.
I'm trying to retrofit some tables to an existing database. The existing database has equipment numbers and I'm trying to add in tables with more information on that equipment. Ideally, I'd like to make the table titles the ID numbers and set those as the PK of that table, making the ID numbers in the equipment list the FK.
Is it possible to set the table title as the PK? Here's an example of one of the tables, and I'd like to make "E0111" the PK.
CREATE TABLE E0111(
EQUIPMENT Varchar(200),
MAINTENANCE varchar(200),
CYCLE varchar(200)
);
No you can't do this because the primary key needs to be unique for every row of your table. If you "could" use the table name as the primary key it would be the same for every row.
You should use a unique column in your table as the primary key.
Also, I have no idea how you could achieve this with SQLite or any DBMS.
First thing before I even get anywhere near answering the question about the table names being primary keys, we need to take a step back.
You should NOT have a table for each piece of equipment.
You need an Equipment table, that will store all of your pieces of Equipment together. I assume you have that already in the existing database.
Hopefully it is keyed with a Unique Identifier AND an Equipment Number. The reason for having a separate Unique Identifier, is that your database server uses this for referential integrity and performance - this is not a value that you should show or use anywhere other than inside the database and between your database and whatever application you are using to modify the database. It should not typically be shown to the user.
The Equipment Number is the one you are familiar with (ie 'E0111'), because this is shown to the User and marked on reports etc. The two have different purposes and needs, so should not be combined into a single value.
I will take a stab at what your Equipment table may look like:
EquipmentId int -- database Id - used for primary key
EquipmentName Varchar(200) -- human readable
EquipmentDescription Text
PurchaseDate DateTime
SerialNumber VarChar(50)
Model Varchar(200)
etc..
To then add the Maintenance Cycle table as you propose above it would look like:
MaintenanceId int -- database Id - used for primary key this time for the maintenance table.
EquipmentId int -- foreign key - references the equipment table
MaintenanceType Varchar(200)
DatePerformed DateTime
MaintenanceResults VarChar(200)
NextMaintenanceDate DateTime
To get the results about the Maintenance Cycle for all equipment, you then JOIN the tables on the 2 EquipmentIds, ie
SELECT EquipmentName, EquipmentDescription, SerialNumber, MaintenanceType DatePerformed
FROM Equipment
JOIN MaintenanceCycle ON Equipment.EquipmentId = Maintenance.EquipmentId
WHERE EquipmentName = 'E0111'
You cannot make the name of the table a primary key.
All primary keys should be unique and a table column not table name. This is the general rule of thumb for a priamry key. There are plenty of resources on the internet about Primary keys.
Here are just afew:
http://www.w3schools.com/sql/sql_primarykey.asp
http://database-programmer.blogspot.co.uk/2008/01/database-skills-sane-approach-to.html
The name of a table should be descriptive of what is hold within it. See that data table as a drawer where you shall label what it contains.
In my humble point of view, the ID of an equipement shall only be labeled as-is on the equipement in question. Otherwise, in your database, it shall be the table Equipments that prevails with the ID of each piece of equipment you have.
Then, if you have other equipment-related information to save, add another table with the kind of information it shall contains, with the ID of the related equipment for which this information is saved.
For example, let's say we hold a maintenance schedule over your equipment.
Equipments
-----------------------------------------------------
Id | Description | Location | Brand | Model
-----------------------------------------------------
1 | Printer/Copier| 1st Floor | HP | PSC1000
Maintenances
---------------------------------------------------------
Id | Description | Date | EquipmentId | EmployeeId
---------------------------------------------------------
Note that the EmployeeId column shall be there only if one requires to know who did what maintenance and when, for instance.
MaintenanceCycles
--------------------------------------------
Id | Code | Description | EquipementId
--------------------------------------------
1 | M | Monthly | 1
This way, every equipment can have its cycle, and even multiple cycles per equipment if required. This lets you the flexibility that you need for further changes.
I have a table which has these columns:
Id (Primary Key): the id.
OwnerId (Foreign Key): the id of the owner, which resides in another table.
TypeId (Foreign Key): the type of thing this record represents. There are a finite number of types, which are represented in another table. This links to that table.
TypeCreatorId (ForeignKey): the owner of the type represented by TypeId.
SourceId (Foreign Key): this isn't important to this question.
I need to constrain this table such that for each Id, there can be only one of each TypeCreatorId. I hope that makes sense!
For SQL Server, you have two options:
create a UNIQUE CONSTRAINT
ALTER TABLE dbo.YourTable
ADD CONSTRAINT UNIQ_Id_TypeCreator UNIQUE(Id, TypeCreatorId)
create a UNIQUE INDEX:
CREATE UNIQUE INDEX UIX_YourTable_ID_TypeCreator
ON dbo.YourTable(Id, TypeCreatorId)
Basically, both things achieve the same thing - you cannot have two rows with the same (Id, TypeCreatorId) values.
Simply create a unique index on OwnerId and TypeCreatorId.
An example using MySQL (sorry, I don't use SQL Server):
alter table yourTable
add unique index idx_newIndex(OwnerId, TypeCreatorId);
Example. I'll just put here what would happen with this new unique index:
OwnerId | TypeCreatorId
--------+--------------
1 | 1
1 | 2 -- This is Ok
2 | 1 -- Ok too
2 | 2 -- Ok again
1 | 2 -- THIS WON'T BE ALLOWED because it would be a duplicate
I have a table which stores all item information and its id. Now I want to create an table with all customers and log which item who bought. What is the best solution for this? I guess it is not very efficient if store it like this:
|customer_id | username | password | boughtproducts |
| 1 | herbert |123 |productid1,pid2...|
How would you do it?
A simpler way to deal with this situation is the following:
Table Customer:
customer_id | username | password
Table Product:
product_id | productName | ...
Table Sales:
sale_id | customer_id | product_id | Time of sale
This way, using the table 'Sales', you will store all the sales of every customer and product.
The customer_id in 'Sales' is a foreign key from 'Customer' table, and product_id in 'Sales' is a foreign key from 'Product' table.
I hope this answered your question
There are numerous examples of this type of schema available on the web.
But in summary your DB may take the form of...
Customer table : One customer can have many..
Order table : One order can have many..
OrderLine table : One orderline will be related to one...
Product table. (And one Product will be related to may OrderLines)
So OrderLine will contain a ProductID and Quantity. You can then JOIN tables and make a full Order.
I would actually go with 2 more tables. One for Customer and then a second for Products they bought Like So:
Customer
CustomerID|Username|Password
PUrchases:
CustomerID|ProductID|Date| etc
have one Customers Table // store details of the customers
have once Products Table // store details of the products
have one Customers_products Table
|primary_key|customer_id | product_id |
| | 1 | 1 |
| | 1 | 2 |
There is Many to Many Relationship between Customers and Products. One customer can buy many products, similarly one product can be bought by many customers. So standard way to implement many to many relationships, is to have one more table, and this new table will contain primary keys from both tables.
Primary Key can be AutoIncremented, or a composite key of both the foreign keys.
I understand the value of primary keys.
I understand the value of indexes.
Should every MySQL table have an auto-incremented primary key (ideally with INT field type)?
Update
#Raj More's answer seems most efficient. The issue when I think about it, however, is how this auto-incremented primary key ID will relate to other tables. For example:
table 1
ID | firstname | lastname | email
----------------------------------------
1 | john | doe | 1#email.com
2 | sarah | stow | 2#email.com
3 | mike | bro | 3#email.com
table 2
ID | memberid | display | address
--------------------------------------------
1 | 1 | funtime zone | 123 street
2 | 3 | silly place llc | 944 villa dr
In the example above, a consumer may come to the site and choose to register for a free product/service. If the consumer chooses, they are able to give additional information (stored in table 2) for additional mailing, etc. The problem I see is in how these tables relate to the 'primary key auto-incremented field'. In table 2, the 'memberid' relates to table 1's ID but this is not 'extremely' clear. Any new information placed into table 2 will increment by 1 whereas not all consumers will choose to participate in the table 2 required data.
I am not a huge fan of surrogate keys. I have yet to see a scenario where I would prefer to use one for every table of a database.
I would say No.
Read up on this answer: surrogate-vs-natural-business-keys
The above may be seen as sarcastic or flaming (despite the surprisingly many upvotes) so it's deleted.
In the general case, there have been many questions and answers on surrogate and natural keys so I felt this question is more like a duplicate. My view is that surrogate keys are fine and very useful, mainly because natural keys can lead to very big primary keys in the low end of a chain of connected tables - and this is not handled well by many RDBMS, clustered indexes get big, etc. But saying that "every MySQL table should have an auto-incremented primary key" is a very absolute statement and I think there are cases when they really offer little or nothing.
Since the OP updated the question, I'll try to comment on that specific topic.
I think this is exactly a case where an autoincrementing primary key is not only useless but adds negative value. Supposing that table1 and table2 are in 1:1 relationship, the memberid can be both the Primary Key and a Foreign Key to table1.
Adding an autoincrementing id column adds one index and if it's a clustered one (like InnoDB PK indexes) increases the size of the memberid index. Even more, if you have such an auto-incrementing id, some JOIN of table2 to other tables will have to be done using this id (the JOINs to tables in 1:n relation to table2) and some using memberid (the JOINs to tables in 1:n relation to table1). If you only have memberid both these types of JOINs can be
done using memberid.
I am a huge fan of surrogate keys. I have yet to see a scenario where I would prefer not use one.
I would say Yes.
Read up on this answer Surrogate vs. natural/business keys
Edit
I will change my answer to include the following:
There are certain scenarios that I now use the actual value as a surrogate key:
DimDate (20151031, 20151101, 20151102....)
DimZipCode (10001, 10002, 10003...)
Everything else gets Surrogate Keys.
Yes, with one exception:
A table which implements a n:m relationship between two other tables, a pure link table, does not need such a field if it has two fields only, referencing the two primary keys of the linked tables. The primary key of the link table then consists of the two fields.
As soon as the link table has extra information, it needs a simple single-field primary key.
Having said that, there may be more exceptions; database design is a very broad field...
EDIT: Added more in the previous sentence.