I am trying to add check constraint in my table that prevents adding more data into a table if the sum of rows shop_id is greater than 3. I have written the following code and its just not working. Kindly check this and guide me.
ALTER TABLE kinect_temp_data
ADD CONSTRAINT my_const CHECK (sum(distinct(shop_id))<3)
The above query runs successful,but it does not create any effect and i can still able to add more rows, and when i query this, it display that no check constraint was added.
SHOW CREATE TABLE kinect_temp_data
Output
CREATE TABLE `kinect_temp_data` (
`cart_number` int(11) NOT NULL AUTO_INCREMENT,
`product_id` varchar(50) NOT NULL,
`shop_id` varchar(50) NOT NULL,
`product_name` varchar(50) NOT NULL,
`item_number` varchar(50) NOT NULL,
`image1_path` varchar(50) NOT NULL,
`image2_path` varchar(50) NOT NULL,
`image3_path` varchar(50) NOT NULL,
`price` int(11) NOT NULL,
PRIMARY KEY (`cart_number`)
) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=latin1
Kindly check this and guide me what i am doing wring here.
Thanks.
MySQL don't support check constraints -- they are ignored.
But you can use BEFORE INSERT and BEFORE UPDATE triggers to realize such functionality.
There is good explanation
Related
Continuation from this question:
PDO query updating a datetime column not in query
A column in my table called lastLoginDate was being automatically updated even though my prepared statement did not include said column.
Apparently, when I created the new column, a trigger was set.
Upon using the command SHOW CREATE TABLE table_name, I returned the following results:
CREATE TABLE `users_edi` (
`username` varchar(30) NOT NULL DEFAULT '',
`fullname` varchar(50) DEFAULT NULL,
`userlevel` tinyint(1) unsigned NOT NULL,
`ipaddress` varchar(30) DEFAULT NULL,
`email` varchar(150) DEFAULT NULL,
`entrydate` datetime DEFAULT NULL,
`division` varchar(35) DEFAULT NULL,
`password` varchar(32) DEFAULT NULL,
`userid` varchar(32) DEFAULT NULL,
`timestamp` int(11) unsigned NOT NULL,
`job_title` varchar(30) DEFAULT NULL,
`dept` varchar(50) DEFAULT NULL,
`phone` varchar(11) DEFAULT NULL,
`lastLoginDate` datetime DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP, // <-- here
PRIMARY KEY (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
The table is years old. I just created the column and somehow, a trigger was set to it (I guess).
Regardless, I tried to remove it using the following command:
ALTER TABLE `users_edi`
`lastLoginDate` datetime DEFAULT NULL
But I only get the following error:
[Err] 1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '`lastLoginDate` datetime DEFAULT NULL' at line 4
How do I remove this trigger using the ALTER TABLE command or any other command?
ALTER TABLE users_edi MODIFY COLUMN lastLoginDate DATETIME DEFAULT NULL;
You might like to read this page on ALTER TABLE: https://dev.mysql.com/doc/refman/8.0/en/alter-table.html
I'm trying to set up a reference between two tables, and I keep running into this error when I load the page.
Error creating table: Cannot add foreign key constraint
This is the 'calendars' table:
calendars table image
And this is the current query I am running to create the table:
CREATE TABLE `'.$classTableName.'`(
classID INT(11) NOT NULL,
name VARCHAR(255) NOT NULL,
users INT(11) NOT NULL,
files INT(11) NOT NULL,
chats INT(11) NOT NULL,
deadlines INT(11) NOT NULL,
calendar INT(11) NOT NULL,
PRIMARY KEY (classID),
FOREIGN KEY (calendar) REFERENCES calendars(classID)
) ENGINE=INNODB;
Any help would be appreciated! :)
Had to index calendars.classID, as pointed out by Basmar.
This is the query I have used for creating the table
CREATE TABLE IF NOT EXISTS `logging_api_request_js` (
`id` int(30) unsigned NOT NULL AUTO_INCREMENT,
`log_message` longtext,
`level` varchar(10) DEFAULT NULL,
`ip_address_merchant` varchar(45) DEFAULT NULL,
`ip_address_customer` varchar(45) DEFAULT NULL,
`creationTime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`updateTime` timestamp NULL DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=11
It showed an error Incorrect table definition; there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause
When I googled I saw that in the mysql 5.6. version this issue / restriction has been took off.But i wont be able to upgrade mysql right now.
Is there any work around for this,whith out changing the table structure to dump this using mysql?Please help.Im having little knowledge about the db operations.Do help.Thanks
You could remove ON UPDATE CURRENT_TIMESTAMP and create trigger.
DROP TRIGGER IF EXISTS `update_logging_api_request_js`;
DELIMITER //
CREATE TRIGGER `update_logging_api_request_js` BEFORE UPDATE ON `logging_api_request_js`
FOR EACH ROW BEGIN
SET NEW.updateTime = NEW.creationTime;
END
//
DELIMITER ;
Hi any one please help i have a contact table in which i can Insert,Delete,Modify database using PHP web pages....but only current changes will be updated to database. what i want is how i can maintain history of database...
Is there any tutorial for this using (PHP/MYSQL).
I tried creating version of MySQL table for patient... how to proceed further.
CREATE TABLE IF NOT EXISTS `contact` (
`name` varchar(30) NOT NULL,
`phone` varchar(12) NOT NULL,
`mobile` varchar(12) NOT NULL,
`email` varchar(30) NOT NULL,
`address` text NOT NULL,
`conid` int(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`conid`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=4 ; # MySQL returned an empty result set (i.e. zero rows).
CREATE TABLE IF NOT EXISTS `contactversion` (
`name` varchar(30) NOT NULL,
`phone` varchar(12) NOT NULL,
`mobile` varchar(12) NOT NULL,
`email` varchar(30) NOT NULL,
`address` text NOT NULL,
`conid` int(11) NOT NULL,
`revision_id` int(11) AUTO_INCREMENT,
type ENUM('INSERT', 'UPDATE', 'DELETE') NOT NULL,
`change_time` DEFAULT current_timestamp,
PRIMARY KEY (`revision_id`)
);
what to do next....
When running the queries to contact, just simply run this right before to take the current contact and copy it in your revision table...
"INSERT INTO
contactversion (name,phone,mobile,email,address,conid,type)
SELECT
name,phone,mobile,email,address,conid,'".$type."' as type
FROM contact
WHERE conid='".$conid."'"
Both tables will require to be identical, with contactversion having type and change_time as additionnal last columns.
It is obvious that this query should be ran before UPDATE and DELETE of the contact table, but after an INSERT. If you are updating multiple contacts with another where clause than the conid, you'll want to consider building the where statement in a variable to use it inside the INSERT's SELECT and the UPDATE/DELETE
While creating contactversions table make sure conid should not be primary key and auto incremented. I hope that is causing the problem.
I have four tables, namely
countries,states,cities,areas
which will be the best feasible solution for my database table
Method A :
CREATE TABLE IF NOT EXISTS `countries` (
`id` int(11) auto_increment NOT NULL,
`name` varchar(50) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE(`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE IF NOT EXISTS `states` (
`id` int(11) auto_increment NOT NULL,
`name` varchar(50) NOT NULL,
`country_id` int(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE(`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE IF NOT EXISTS `cities` (
`id` int(11) auto_increment NOT NULL,
`name` varchar(50) NOT NULL,
`state_id` int(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE(`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE IF NOT EXISTS `areas` (
`id` int(11) auto_increment NOT NULL,
`name` varchar(50) NOT NULL,
`zipcode` int(11) NOT NULL,
`city_id` int(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE(`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
or Method B :
CREATE TABLE IF NOT EXISTS `countries` (
`id` int(11) auto_increment NOT NULL,
`name` varchar(50) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE(`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE IF NOT EXISTS `states` (
`id` int(11) auto_increment NOT NULL,
`name` varchar(50) NOT NULL,
`country_id` int(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE(`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE IF NOT EXISTS `cities` (
`id` int(11) auto_increment NOT NULL,
`name` varchar(50) NOT NULL,
`state_id` int(11) NOT NULL,
`country_id` int(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE(`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE IF NOT EXISTS `areas` (
`id` int(11) auto_increment NOT NULL,
`name` varchar(50) NOT NULL,
`zipcode` int(11) NOT NULL,
`city_id` int(11) NOT NULL,
`state_id` int(11) NOT NULL,
`country_id` int(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE(`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Thank you..
The first is less likely to have problems with synchronization.
The second will offer better performance through denormalization.
Possible related thread: What is a good way to denormalize a mysql database?
The second version will lead to major headaches if mismatched data is entered. Take the following sample data:
countries: Canada, USA
states: Saskatchewan, Michigan
cities: Saskatoon, Detroit
zipcode: 90210 (california)
insert into area (...) ('Canada', 'Michigan', 'Saskatoon', 90210)
all individually valid, but the entire record is utterly wrong. Yet, by your design, it's supposed to be valid.
It probably depends on what queries you are going to run on those tables. In general, A is normalized whereas B is not (A will use less space).
I would start with Method A, but if it turns out performance requires the additional columns further down the chain, I'd add them only as needed.
Just be sure to make your _id columns indexes.
I prefer Method A at first glance, but without knowing specifics about what you want the relationships and constraints to be, it's impossible to say categorically that one is "better" than the other. Follow your application's functional requirements.
Congratulations on looking towards a normalised approach: it's nice to see!
I personally would choose the first one [Method A]. If you know, for example, the city ID of an area, then you automatically know the state ID and the country ID. While the second one may be a bit more convenient, you may run into issues down the line if say, a city moved to a different state.
It's always best to start with the normalized form. I would only suggest Method B if you had your RDBMS automatically managing cached column updates. For example, if you mistakenly placed Los Angeles in Michigan, you would need to update multiple locations (unless you had triggers that would update cascading pieces of information in denormalized tables). But without triggers, Method A is without a doubt the best form.
This is assuming of course that your constraints match the ones implicitly dictated by common interpretation when viewing Method A's definition.