I want to create a table and avoid duplicated entries, by creating a PRIMARY KEY. The problem is I don't know which columns I should add to this KEY. Consider the next table:
CREATE TABLE `customers` (
`id_c` int(11) unsigned NOT NULL,
`lang` tinyint(2) unsigned NOT NULL,
`name` varchar(80) collate utf8_unicode_ci NOT NULL,
`franchise` int(11) unsigned NOT NULL,
KEY `id_c` (`id_c`),
KEY `lang` (`lang`),
KEY `franchise` (`franchise`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
id_c: Id of customer. It can be an enterprise. Suppose McDonald's
lang: Contact language.
boss: Boss' name
franchise: If not zero, it is a franchise. McDonald's in Rome, Paris, London...
As you can see, each ENTERPRISE can have different central "shops" in each country (contact language), but also different franchises in each city (where boss' name would be different).
I want to be able to INSERT new rows where the id_c, lang can be not-distinct (many franchises in same country). But name has to be distinct only if (id_c,lang) is the same (for other id_c,lang combination... name could be the same). And franchise can be the same too only if it has not been assigned in the same (id_c,lang) pair.
I was thinking about a PRIMARY KEY (lang,name), but it might not be the best way. Is this table structure just too complex?
you need to create a multiple column UNIQUE constraint,
CONSTRAINT tb_uq UNIQUE (id_c,lang, name)
or set them as the primary key,
CREATE TABLE `customers`
(
`id_c` int(11) unsigned NOT NULL,
`lang` tinyint(2) unsigned NOT NULL,
`name` varchar(80) collate utf8_unicode_ci NOT NULL,
`franchise` int(11) unsigned NOT NULL,
KEY `id_c` (`id_c`),
KEY `lang` (`lang`),
KEY `franchise` (`franchise`),
CONSTRAINT tb_PK PRIMARY KEY (id_c,lang, name) --- <<== compound PK
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
If i get your question right...u are asking which columns to choose...and not HOW to do it?Correct?
So i'd guess that franchise number is not a boolean(YES/NO) thing but holds a number unique for each shop?...each country? If thats the case then go with id_c and franchise.
If not you can choose all 4 of them to be the key...but i think thats not a good practise.In that case i'd say that you should add one more column(trueID for example - autoincrement integer) and use this one as your primary key.
Just give Id as primary key. Because using Id_c you can get other column values. As you see the best advice is to create your Primary id should be in first column.
Related
I am creating a database for selling houses.
I have a parent table that I am calling location that has three columns :
locationLat : the latitude of location of property
locationLong : the longitude of the property
locationName : an alternative name that i can use to identify the location of the property by name
Both locationLat and locationlong make up a composite primary key of this table.
Then I have a child table called houseToLet, this table only stores the houses that are for letting. I have similar different tables houseToBuy, fullyFurnished, landtoSell etc. The table for houseTolet has a composite primary key like the location table above i.e locationLat, locationLong and a foreign composite key location_locationLat and location_locationLong that references the location table.
Then I have another table called generalFeatures. This the table where I store general features of all the properties I am selling. So generalFeatures table is a child table of houseTolet and Housetobuy as well as Fullyfurnished tables,
When I insert rows into the location table, I find no problem as it is the parent table. When i insert rows into houseTolet table I find no problem since it is a child table and I will have inserted the parent location table already. However when I insert into the generalFeatures table I get into problem since it is a child table of housetoBuy as well as other tables including Fullyfurnished.
Please assist me to know how I can do this.
CREATE TABLE IF NOT EXISTS `foreign`.`location` (
`locationLat` DECIMAL(10,8) NOT NULL,
`locationLong` DECIMAL(11,8) NOT NULL,
`locationName` VARCHAR(35) NOT NULL,
PRIMARY KEY (`locationLat`, `locationLong`))
ENGINE = InnoDB
CREATE TABLE IF NOT EXISTS `location`.`housetolet` (
`locationLat` DECIMAL(10,8) NOT NULL,
`locationLong` DECIMAL(11,8) NOT NULL,
`type` ENUM('gatedCommunity', 'standalone', 'apartment') NOT NULL,
`location_locationLat` DECIMAL(10,8) NOT NULL,
`location_locationLong` DECIMAL(11,8) NOT NULL,
PRIMARY KEY (`locationLat`, `locationLong`),
INDEX `fk_housetolet_location_idx` (`location_locationLat` ASC, `location_locationLong` ASC))
CREATE TABLE IF NOT EXISTS `foreign`.`generalfeatures` (
`locationLat` DECIMAL(10,8) NOT NULL,
`locationLong` DECIMAL(11,8) NOT NULL,
`livingAreaAndSize` INT NOT NULL,
`bedrooms` TINYINT(4) NOT NULL,
`bathrooms` TINYINT(4) NOT NULL,
`masterEnsuite` TINYINT(1) NOT NULL,
`bedroomsWithBathrooms` TINYINT(4) NOT NULL,
`kitchenAndSize` TINYINT(4) NOT NULL,
`parkingAndSlots` TINYINT(4) NOT NULL,
`swimmingPool` TINYINT(1) NOT NULL,
`liftsAndNumber` TINYINT(4) NOT NULL,
`CCTV` TINYINT(1) NOT NULL,
`sizeOfLand` INT(11) NOT NULL,
`borehole` TINYINT(1) NOT NULL,
`housetobuy_locationLat` DECIMAL(10,8) NOT NULL,
`housetobuy_locationLong` DECIMAL(11,8) NOT NULL,
`housetolet_locationLat` DECIMAL(10,8) NOT NULL,
`housetolet_locationLong` DECIMAL(11,8) NOT NULL,
`fullyfurnished_locationLat` DECIMAL(10,8) NOT NULL,
`fullyfurnished_locationLong` DECIMAL(11,8) NOT NULL,
PRIMARY KEY (`locationLat`, `locationLong`),
INDEX `fk_generalfeatures_housetobuy1_idx` (`housetobuy_locationLat` ASC, `housetobuy_locationLong` ASC),
INDEX `fk_generalfeatures_housetolet1_idx` (`housetolet_locationLat` ASC, `housetolet_locationLong` ASC),
INDEX `fk_generalfeatures_fullyfurnished1_idx` (`fullyfurnished_locationLat` ASC, `fullyfurnished_locationLong` ASC),
CONSTRAINT `fk_generalfeatures_housetobuy1`
FOREIGN KEY (`housetobuy_locationLat` , `housetobuy_locationLong`)
REFERENCES `foreign`.`housetobuy` (`locationLat` , `locationLong`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_generalfeatures_housetolet1`
FOREIGN KEY (`housetolet_locationLat` , `housetolet_locationLong`)
REFERENCES `foreign`.`housetolet` (`locationLat` , `locationLong`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_generalfeatures_fullyfurnished1`
FOREIGN KEY (`fullyfurnished_locationLat` , `fullyfurnished_locationLong`)
REFERENCES `foreign`.`fullyfurnished` (`locationLat` , `locationLong`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
I want to be able to insert rows into generalFeatures table for houses to Let without getting foreign key constraints that I need to update other tables like houseTobuy or fullyFurnished first, this is because in a particular instance I will be updating a particular type of a house only but not many options. A house to let cannot be at the same time be a house to buy in my case.
Your database design has flaws. Namely, you are storing in multiple tables information that could be represented as a single record. As it is, it looks like all tables could be merged into main table locations :
the house* tables (houseToLet, houseToBuy, ...) are just there to store the current status of the location (to let, to buy, ...) : this could be represented as an ENUM field in the location table (or as several boolean columns if more than one status can be enabled at a time)
the generalFeatures table also seems to contain a single record for each location, hence all of its fields could be moved to the location table.
Using a single table appears like the right design for your use case (and it sure avoids issues with foreign constraints...).
Other considerations : use an autoincremented integer as primary key instead of a composite key (for this, you can create a UNIQUE constraint).
Here is a sample DDL for your table :
CREATE TABLE IF NOT EXISTS `foreign`.`location` (
-- primary key
`id` INT AUTO_INCREMENT,
PRIMARY KEY (`id`),
-- original columns
`locationLat` DECIMAL(10,8) NOT NULL,
`locationLong` DECIMAL(11,8) NOT NULL,
`locationName` VARCHAR(35) NOT NULL,
-- house status
`status` ENUM('toLet', 'houseToBuy', 'fullyFurnished', 'landtoSell') NOT NULL,
-- columns from `generalfeatures`
`livingAreaAndSize` INT NOT NULL,
`bedrooms` TINYINT(4) NOT NULL,
`bathrooms` TINYINT(4) NOT NULL,
`masterEnsuite` TINYINT(1) NOT NULL,
`bedroomsWithBathrooms` TINYINT(4) NOT NULL
-- other columns from `generalfeatures`...
)ENGINE = INNODB;
What I have now is table that is "hardcoded" to have a relationship between two of the same table with two foreign keys to that table.
Before 'Relationship' table:
CREATE TABLE IF NOT EXISTS `Item_To_Item` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`item1_id` INT(11) NOT NULL,
`item2_id` INT(11) NOT NULL,
`relationship` ENUM('requires', 'mutually_requires', 'required_by', 'relates', 'excludes') NULL DEFAULT NULL,
`description` VARCHAR(1000) NULL DEFAULT NULL,
PRIMARY KEY (`id`),
CONSTRAINT `fk_Item1_Id`
FOREIGN KEY (`item1_id`)
REFERENCES `Item` (`id`)
CONSTRAINT `fk_Item2_Id`
FOREIGN KEY (`item2_id`)
REFERENCES `Item` (`id`)
So before this had a double many to one reference on the item table to fill the two foreign keys.
There is a need now to expand this relationship to be more general between tables in the db (Enum, Tag, feature etc). So that now Items can relate to items, items can relate to tags, tags can relate to tags etc with the enum relationship value.
What I am thinking for the general table is adding a type table, so each item, tag, etc can be identified, and then restructuring the relationship table to be something like this:
CREATE TABLE IF NOT EXISTS `Relationship` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`relater_id` INT(11) NOT NULL,
`relatee_id` INT(11) NOT NULL,
`relationship` ENUM('requires', 'mutually_requires', 'required_by', 'relates', 'excludes') NULL DEFAULT NULL,
`description` VARCHAR(1000) NULL DEFAULT NULL,
`relater_type_id` INT(11) NULL,
`relatee_type_id` INT(11) NULL,
PRIMARY KEY (`id`),
INDEX `fk_Relatee_Id` (`relatee_id` ASC),
INDEX `fk_Relater_Id` (`relater_id` ASC),
CONSTRAINT `fk_Relater_Id`
FOREIGN KEY (`relater_id`)
CONSTRAINT `fk_Relatee_Id`
FOREIGN KEY (`relatee_id`)
So that now you can identify what type of items are being related by the type_id and table and this can be opened up so any two table ids can go into the Relater and Relatee foreign key columns.
The problem is that I do not know how to have such generality with foreign keys. I believe they can only reference one table so I am not sure how to do what I want with a general key reference. Also, I can see a problem with bidirectional relationships where A mutually Requires B and B mutually Requires A being redundant data. I could block this redundancy in my application, but I would constantly have to check for two sided A to B || B to A. I was wondering the best way to accomplish what I am trying to do. Thank you.
Edit: Maybe using some kind of base type for my (item, feature, tag) could help me?
Edit: I don't think the answer is as simple as inheritance. At least from what I can tell. My problem is that I want to relate two general items no matter the type. I don't want 20 columns that have to be null because it is not that specific type. I just want to be able to pass two ids and therefore two type_ids into the relationship so I can relate any two objects.
One potential solution is to implement object_type and object_index tables:
CREATE TABLE object_type (
`object_type_id` int(11) NOT NULL AUTO_INCREMENT,
`object_type` varchar(30) NOT NULL,
PRIMARY KEY (`object_type_id`),
UNIQUE (`object_type`));
CREATE TABLE object_index (
`object_id` int(11) NOT NULL AUTO_INCREMENT,
`object_type_id` int(11) NOT NULL,
PRIMARY KEY (`object_id`),
UNIQUE (`object_type_id`, `object_id`));
and define your relations against that table only.
CREATE TABLE IF NOT EXISTS `Relationship` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`relater_id` INT(11) NOT NULL,
`relatee_id` INT(11) NOT NULL,
`relationship` ENUM('requires', 'mutually_requires', 'required_by', 'relates', 'excludes') NULL DEFAULT NULL,
`description` VARCHAR(1000) NULL DEFAULT NULL,
PRIMARY KEY (`id`),
INDEX `fk_Relatee_Id` (`relatee_id` ASC),
INDEX `fk_Relater_Id` (`relater_id` ASC),
CONSTRAINT `fk_Relater_Id`
FOREIGN KEY (`relater_id`)
references object_index (`object_id`),
CONSTRAINT `fk_Relatee_Id`
FOREIGN KEY (`relatee_id`)
references object_index (`object_id`));
Next each of your object tables are defined such they relate back to the object_index on the unique (object_type_id, object_id) tuple. In this example each tables default and check constrained object_type_id should be unique:
CREATE TABLE table1 (
`object_id` int(11) NOT NULL,
`object_type_id` int(11) NOT NULL DEFAULT 1 CHECK (object_type = 1),
`col1` varchar(4),
PRIMARY KEY (`object_id`),
CONSTRAINT fk_t1_ob_idx
FOREIGN KEY (`object_type_id`, `object_id`)
REFERENCES object_index (`object_type_id`, `object_id`));
In MySQL 5.6 and above you could define a virtual/computed column on each table to match object_type_id from the object_index instead of a stored physical column.
In MySQL 8.0 and above you might be able to define a function based index on each table that includes the discriminator object_type_id as an expression instead of as a physical or virtual column in the table.
I've been thinking on this problem for fews days and I still can't find a way to do what I want.
Below is how my database is currently designed (it's where I'm stuck) :
This is what I want :
a User can create multiple PriceSheets. A User can give a PriceSheet any name he wants. There are two PriceSheets types : "Lab Fulfillment", or "Self Fulfillment".
if the User chooses "Lab Fulfillment", he can import all or part of the Products of one of the predefined Labs. (I rephrase : there are few Labs that come with a predefined list of Products). The User will only be able to customize the price. He can't add custom products to this PriceSheet.
if the User chooses "Self Fulfillment", he can add his own products, and can personalize each field (name, cost, price, dimension_h, dimension_l).
I don't know how to link the tables between them. If I put the predefined Products in the Products table and set a Many-to-Many relationship between PriceSheets and Product, the default price of a predefined Product will be overwritten when a User customizes it, which is not what I want.
Also, I want the default values of my predefined Products to be only once in my database. If 100 users uses the predefined Products, I don't want the default cost to be in my database 100 times.
Don't hesitate to ask for precisions, I had trouble making this question clear and I think it's still not totaly clear.
Thanks in advance for your help
OK, database normalization 101. Lots of ways to do this, would take me a day to really optimize all this, this should help:
User
Lab
Product
id name cost dimension .....
1 a
2 b
3 c
4 d
So those three tables are fine. All your products will go in the Product table. No foreign keys in any of those tables.
PriceSheet
user_id custom_price product_id type
1 1.99 1 lab-fulfillment
0 NULL 2 self-fulfillment
1 5.99 3 lab-fulfillment
So a user can have as many price sheets as they want, and they can only adjust the price of a product. This can actually be normalized further if you so wish:
PriceSheet (composite key on id, user_id, FK user_id)
id user_id
0 0
1 1
2 1
LabPriceSheet (you could add an id, might be better, or you could use a composite key, stricter)
PriceSheet_id custom_price lab_product_id
0 1.99 0
2 5.99 1
CustomPriceSheet
PriceSheet_id custom_product_id
1 0
With foreign keys as appropriate. This now makes MySQL restrict the custom_price, rather than in PHP (although you would still have to deal with ensuring correct INSERT!).
Now, to deal with who adds the products:
CustomProduct
id user_id product_id timestamp
0 3 2 ...
LabProduct
id lab_id product_id timestamp
0 0 1 ...
1 0 3 ...
So let's double check:
This is what I want :
a User can create multiple PriceSheets. check A User can give a PriceSheet
any name he wants. check There are two PriceSheets types : "Lab
Fulfillment", or "Self Fulfillment". check
if the User chooses "Lab Fulfillment", he can import all or part of the Products of one of the predefined Labs. (I rephrase : there are few Labs that come with a predefined list of Products). The User will only be able to customize the price. He can't add custom products to this PriceSheet.
Yup, because he would create a LabPriceSheet that can only add lab_product_id. Custom price is there too, that overrides the default price in product table.
if the User chooses "Self Fulfillment", he can add his own products, and can personalize each field (name, cost, price, dimension_h, dimension_l).
Yup, he would add a product (you would need to check if a similar one exists, else return the id of the existing product in the product table), and then that would also be an entry in CustomProduct.
I don't know how to link the tables between them. If I put the predefined Products in the Products table and set a Many-to-Many relationship between PriceSheets and Product, the default price of a predefined Product will be overwritten when a User customizes it, which is not what I want.
Yeah that won't happen :) Never (very very rarely) implement many-many rels.
Also, I want the default values of my predefined Products to be only
once in my database. If 100 users uses the predefined Products, I
don't want the default cost to be in my database 100 times.
Of course.
Let me know if you want the MySQL code, I assume you're good! Remember to use InnoDB and properly configure your MySQL configuration!
EDIT
I felt like helping you out with a copy and paste thing. I like copy and paste things. Also, there's a redundant user_id column in the blurb above which I fixed in an earlier edit.
SET GLOBAL innodb_file_per_table = 1;
SET GLOBAL general_log = 'OFF';
SET FOREIGN_KEY_CHECKS=1;
SET GLOBAL character_set_server = utf8mb4;
SET NAMES utf8mb4;
CREATE DATABASE SO; USE SO;
ALTER DATABASE SO CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;
CREATE TABLE `User` (
`id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
`email` VARCHAR(555) NOT NULL,
`password` VARBINARY(200) NOT NULL,
`username` VARCHAR(100) NOT NULL,
`role` INT(2) NOT NULL,
`active` TINYINT(1) NOT NULL,
`created` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
`modified` DATETIME ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE `Lab` (
`id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
`name` VARCHAR(1000) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE `Product` (
`id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
`name` VARCHAR(1000) NOT NULL,
`password` VARBINARY(200) NOT NULL,
`cost` DECIMAL(10, 2) NOT NULL,
`price` DECIMAL(10, 2) NOT NULL,
`height` DECIMAL(15, 5) NOT NULL,
`length` DECIMAL(15, 5) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE `CustomProduct` (
`id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
`user` BIGINT(20) UNSIGNED NOT NULL,
`product` BIGINT(20) UNSIGNED NOT NULL,
`created` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
FOREIGN KEY (`user`) REFERENCES `User`(`id`),
FOREIGN KEY (`product`) REFERENCES `Product`(`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE `LabProduct` (
`id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
`lab` BIGINT(20) UNSIGNED NOT NULL,
`product` BIGINT(20) UNSIGNED NOT NULL,
`created` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
FOREIGN KEY (`lab`) REFERENCES `Lab`(`id`),
FOREIGN KEY (`product`) REFERENCES `Product`(`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE `PriceSheet` (
`id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
`name` VARCHAR(1000) NOT NULL,
`user` BIGINT(20) UNSIGNED NOT NULL,
PRIMARY KEY (`id`,`user`),
FOREIGN KEY (`user`) REFERENCES `User`(`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE `LabPriceSheet` (
`id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
`price_sheet` BIGINT(20) UNSIGNED NOT NULL,
`lab_product` BIGINT(20) UNSIGNED NOT NULL,
`custom_price` DECIMAL(10, 2) NOT NULL,
PRIMARY KEY (`id`),
FOREIGN KEY (`price_sheet`) REFERENCES `PriceSheet`(`id`),
FOREIGN KEY (`lab_product`) REFERENCES `LabProduct`(`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE `CustomPriceSheet` (
`id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
`price_sheet` BIGINT(20) UNSIGNED NOT NULL,
`custom_product` BIGINT(20) UNSIGNED NOT NULL,
PRIMARY KEY (`id`),
FOREIGN KEY (`price_sheet`) REFERENCES `PriceSheet`(`id`),
FOREIGN KEY (`custom_product`) REFERENCES `CustomProduct`(`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
I have a database I'm trying to create on SQL and I am trying to connect the relationships together. There are three tables: superhero, power, and superheroPower. The tables superhero and power is a many to many relationship which is represented by the table superheroPower.
Is the syntax below correct for foreign keys between tables (and everything else)? Also, is there any other recommendations on these tables in terms of their setup?
CREATE TABLE superhero( id INT NOT NULL AUTO_INCREMENT,
heroName VARCHAR(255) NOT NULL,
firstName VARCHAR(255),
lastName VARCHAR(255),
firstAppearance DATE,
gender VARCHAR(255),
bio TEXT,
universe VARCHAR(255),
PRIMARY KEY(id)
) ENGINE=InnoDB;
CREATE TABLE power(
id INT NOT NULL AUTO_INCREMENT,
name VARCHAR(255) NOT NULL,
description TEXT NOT NULL,
PRIMARY KEY(id)
) ENGINE=InnoDB;
CREATE TABLE superheroPower(
superheroID INT,
powerID INT,
PRIMARY KEY(superheroID, powerID),
FOREIGN KEY(superheroID) REFERENCES superhero(id),
FOREIGN KEY(powerID) REFERENCES power(id)
) ENGINE=InnoDB;
Yes, everything there looks okay. But...
A few notes:
We'd use a shorter datatype for the gender column; I don't see that we'd need 255 characters to express that. (There is a limit on the maximum size of a row which is enforced.) If there only a few values for that, we'd consider ENUM datatype.
We'd also likely add NOT NULL constraints on several of those columns, such as heroname, firstname, lastname. We'd also likely add DEFAULT ''. Sometimes, we really do need to allow NULL values for some reason, but we use NOT NULL wherever we can.
I'm hesitant about the TEXT columns. There's nothing wrong with using TEXT datatype, but I'm just suspicious that those may be "hiding" some information that might better be stored in additional columns.
For the foreign keys, we'd assign a name to the constraints, following the pattern we use, and also likely add ON UPDATE CASCADE ON DELETE CASCADE
CONSTRAINT FK_superheroPower_power FOREIGN KEY (powerID)
REFERENCES power(id) ON UPDATE CASCADE ON DELETE CASCADE
A note about identifiers (table names and column names)
The way we do it, all table name are lower case. (We have a MySQL option set that forces all table names to lower case.) We do this to avoid incompatibility issues for different operating systems/filesystems (some of which are case sensitive, and some are not).
Also, table names are singular. The name of the table names what one row of the table represents. We also don't include _table as part of the name.
Column names in MySQL are never case sensitive, but we always use lower case for the column names as well. We don't "camelCase" our column names, we use underscore character as separators, e.g. power_id vs. powerID, hero_name vs. heroName.
FOLLOWUP
My "notes" above aren't specific rules that must be followed; those are just patterns we use.
Following these patterns does not guarantee that we'll have a successful software, but it does help us.
For your reference, I'll show how these tables would look as a "first cut" from our shop, as an illustration of another pattern; this is not "the right way", it's just "a way" that we've settled on as a team.
CREATE TABLE superhero
( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'pk'
, hero_name VARCHAR(255) NOT NULL COMMENT ''
, first_name VARCHAR(255) NOT NULL DEFAULT '' COMMENT ''
, last_name VARCHAR(255) NOT NULL DEFAULT '' COMMENT ''
, first_appearance DATE COMMENT 'date superhero first appeared'
, gender ENUM('female','male','other') COMMENT 'female,male or other'
, biography_text TEXT COMMENT ''
, universe VARCHAR(255) COMMENT ''
, PRIMARY KEY(id)
, UNIQUE KEY superhero_UX1 (hero_name)
) ENGINE=InnoDB;
CREATE TABLE power
( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'pk'
, name VARCHAR(255) NOT NULL COMMENT ''
, description_text TEXT NOT NULL COMMENT ''
, PRIMARY KEY(id)
, UNIQUE KEY power_UX1 (name)
) ENGINE=InnoDB;
CREATE TABLE superheropower
( superhero_id INT UNSIGNED NOT NULL COMMENT 'pk, fk ref superhero'
, power_id INT UNSIGNED NOT NULL COMMENT 'pk, fk ref power'
, PRIMARY KEY(superhero_id, power_id)
, CONSTRAINT FK_superheropower_superhero
FOREIGN KEY(superhero_id) REFERENCES superhero(id)
ON UPDATE CASCADE ON DELETE CASCADE
, CONSTRAINT FK_superheropower_power
FOREIGN KEY (power_id) REFERENCES power(id)
ON UPDATE CASCADE ON DELETE CASCADE
) ENGINE=InnoDB;
Your design seems on the right track, this is the tables i would have gone with - adding some Indexes for the fields its likely that you will search for and adding the actions needed for the CONSTRAINT keys
CREATE TABLE `_superhero` (
`id` int(11) NOT NULL auto_increment,
`heroName` varchar(255) NOT NULL,
`firstName` varchar(255) default NULL,
`lastName` varchar(255) default NULL,
`firstAppearance` date default NULL,
`gender` enum('Other','Female','Male') default NULL,
`bio` text,
`universe` varchar(255) default NULL,
PRIMARY KEY (`id`),
KEY `indxHname` (`heroName`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `_power` (
`id` int(11) NOT NULL auto_increment,
`name` varchar(255) NOT NULL,
`description` text NOT NULL,
PRIMARY KEY (`id`),
KEY `indx4` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `_superheropower` (
`superheroID` int(11) NOT NULL default '0',
`powerID` int(11) NOT NULL default '0',
PRIMARY KEY (`superheroID`,`powerID`),
KEY `indx1` (`superheroID`),
KEY `indx2` (`powerID`),
CONSTRAINT `fk2` FOREIGN KEY (`powerID`) REFERENCES `_power` (`id`) ON DELETE CASCADE ON UPDATE NO ACTION,
CONSTRAINT `fk1` FOREIGN KEY (`superheroID`) REFERENCES `_superhero` (`id`) ON DELETE CASCADE ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Edit[1]: This is a version of SQL code on how I would do it!!
CREATE TABLE superhero
(
Superheo_id INT NOT NULL AUTO_INCREMENT,
heroName VARCHAR(255) NOT NULL,
firstName VARCHAR(255)NULL,
lastName VARCHAR(255)NULL,
firstAppearance DATE NULL,
gender VARCHAR(255) NULL,
bio TEXT NULL,
universe VARCHAR(255) NULL,
CONSTRAINT SUPERHERO_PK PRIMARY KEY(SUPERHERO_id)
);
CREATE TABLE power
(
POWER_id INT NOT NULL AUTO_INCREMENT,
name VARCHAR(255) NOT NULL,
description TEXT NOT NULL,
CONSTRAINT POWER_PK PRIMARY KEY(POWER_id)
);
CREATE TABLE superheroPower
(
superheroID INT DEFAULT(0) NOT NULL,
powerID INT DEFAULT(0) NOT NULL,
CONSTRAINT SUPERHEROPOWERS_SUPERHERO_FK FOREIGN KEY(superheroID) REFERENCES superhero(id),
CONSTRAINT SUPERHEROPOWERS_POWERS_FK FOREIGN KEY(powerID) REFERENCES power(id)
);
edit[2]:You are able to change null to not null and vise versa depending on if you want a user to move past with out installing the other information. I have never used the Auto_increment before in my sql tables, so for me that is something new I just learned from you
I have a table in that i have unique key .Now because of some reasons i want to update the unique key. AS of now unique key is having 4 columns now i want to add 2 more columns in that
CREATE TABLE abc (
id int(10) unsigned NOT NULL AUTO_INCREMENT,
one varchar(64) NOT NULL,
search_id varchar(64) NOT NULL,
session_id varchar(64) NOT NULL,
pnr varchar(64) NOT NULL,
origin varchar(5) NOT NULL,
destination varchar(5) NOT NULL,
type varchar(15) NOT NULL,
name1 varchar(55) NOT NULL,
name2 varchar(55) NOT NULL,
number varchar(55) DEFAULT '',
text text,
cr_dt timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (id),
UNIQUE KEY aedi_id (one,search_id,session_id,origin,destination,pnr,number) //I have this
UNIQUE KEY aedi_id (one,search_id,session_id,origin,destination,pnr,name1,name2,number) I want this
)
The syntax is:
alter table drop key aedi_id;
alter table add key aedi_id (one, search_id, session_id, origin, destination, pnr, name1, name2, number) ;
Note that a unique key is implemented as an index, which will be used for queries. This means that the order of the columns matters in the key definition -- some orderings will work better for your queries. So, depending on your queries, you may want to re-arrange the columns.