As per the MySQL manual "The CHECK clause is parsed but ignored by all storage engines." So I know the simple solution is out of the question but is there another feasible means of coming to the same outcome? Maybe through some use of triggers or stored procedures? If so how?
Also since it is just "parsed" is that as good as saying avoid using it since it doesn't serve a purpose?
Using MySQL 5.5.11 and InnoDB tables
Take a look at this interesting article
https://wikis.oracle.com/display/mysql/Triggers#Triggers-EmulatingCheckConstraints
I often use that method.
I am using version 5.5.21
you can use ENUM for check constraints
http://dev.mysql.com/doc/refman/5.0/en/enum.html
Related
I have inherited an application that uses MySQL and that is used by a PHP front end. The guy that wrote this system has gone to some fairly convoluted lengths to ensure that codes that users enter are valid - and tat means that these codes also exist in another table.
When I first saw this I wondered why he hadn't used CHECK constraints and let the dbms sort this out - I have visions of a load of different programs implementing the same checks instead of just the one place in the dbms. And then I found out that MySQL doesn't support Check constraints (not strictly true - it supports the syntax but just ignores it).
Is there a way that I can implement Check Constraints in MySQL?
Any hints, suggestions etc, would be great.
You can implement something similar to them with triggers, but MySQL itself (before version 8.0.16) doesn't support CHECK constraints. Don't worry though, it'll let you define them and just silently ignore them!
I'm actually using Mysql + InnoDB and I just got caught by a very troublesome (at least for me) limitation: the trigger cannot act on the same table it was triggered from. Does this apply on MariaDB too? Does it make sense to migrate to MariaDB to overcame this?
Reading the documentation it is not mentioned but some users may address this further.
https://mariadb.com/kb/en/mariadb/documentation/stored-programs-and-views/triggers/trigger-limitations/
Q: Does this apply on MariaDB too?
A: Yes, the limitation applies in MariaDB as well.
This restriction is documented in the MySQL Reference Manual.
"A stored function or trigger cannot modify a table that is already being used (for reading or writing) by the statement that invoked the function or trigger."
(All of the restrictions that apply to a Stored Function also apply to a Trigger.)
Ref: http://dev.mysql.com/doc/refman/5.5/en/stored-program-restrictions.html
This same restriction is also documented in the MariaDB documentation:
https://mariadb.com/kb/en/mariadb/documentation/stored-programs-and-views/stored-functions/stored-function-limitations/
Q: Does it make sense to migrate to MariaDB to overcame this?
A: It may make sense to migrate to MariaDB, but not as a workaround to the issue you've discovered.
Pardon my noob question but was wondering how to change the database context within mysql? I know in SQL Server, it's:
USE [DBName];
so is there an equivalent in mysql?
In MySQL, if you want to change databases, you will also use use:
mysql> use DNNAME;
Same thing: use [database]; (the ; is optional here)
MySQL 5.0 Reference Manual :: 13.8.4 USE Syntax
The use command switches databases in MySQL. The following line
`use [database];`
will switch between databases, where you substitute the actual name of your database for [database], like use db1;.
I want to get the autoincrement id of an insert.
is there a way to do it?
Seeing as you're specifying only mySQL in your tags:
Use LAST_INSERT_ID(). Make sure to read the manual page for the subtleties.
The language you are querying mySQL from may have built-in API functions that do the same thing.
I want to have a field in a Mysql table, which should accept inputs having a fixed size - no more, no less. The input data is a number, but solutions for strings can also be considered, as I have no problem storing this data as varchar like stuff.
To be exact, I want a datatype which will NOT allow me to store a number which is having less than 7 or greater than 7 digits. I dont want to use triggers/stored procedures.
This may be possible with a stored procedure, but I wouldn't do this on database level. Validation like this belongs in your application.
I don't believe there is any way to achieve this in MySQL at present without using triggers or stored procedures. If MySQL supported check constraints then you could do it, but it doesn't, so you can't.
The possible solutions are:
TRIGGER on update/insert.
CHECK constraint, but MySQL parses and promptly discards check constraints.
Application-level validation.
Foreign key to a lookup table containing the 900,000 integers of 7 digits.
The only other suggestion is to migrate to a SQL database that supports CHECK constraints.
Open-source databases that support CHECK constraints include:
PostgreSQL
SQLite
Firebird
Apache Derby
HyperSQL
Every commercial database also supports CHECK constraints.
Basically, MySQL is the only SQL database on the market that doesn't support CHECK constraints!