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!
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!
Is there a way to encrypt a field in a database and still have useful indexes on it?
For example, in the medical arena you need to encrypt patient information. If I do this on a patient name field, is there a way to still be able to have indexes on the decrypted value?
I'm thinking of using AES_ENCRYPT() on the field, but would really like to know if there is a trick to do the indexing on the decrypted value, not on the field's value (which would be encrypted).
AES_ENCRYPT() and AES_DECRYPT() are functions. So the question in more general terms is:
Can MySQL do indexing on functions?
As of MySQL 5.6 the answer is no, although you can see this in other sql engines. For example oracle has done it since 8i and MS SQL has done it since 2000.
It looks like this might be possible in Maria DB 5.2 (https://mariadb.com/kb/en/mariadb/virtual-computed-columns/), which is a community version fork of MySQL.
References:
Is it possible to have function-based index in MySQL?
http://use-the-index-luke.com/sql/where-clause/functions
Say I have a table call ‘users’ with a column ‘order’ and I wish my application code to work across all the database systems out there.
Assume that it is impractical to change the database schema. Even if the schema was change, one of the main database engine will come up with yet another reserved word, so stopping the app working when a database engine is updated.
I would rather not have to process the SQL strings to convert them into the correct form for each database.
'How to find if a column name is a reserved keyword across various databases' partly overlaps with this question.
('Syntax error due to using a reserved word as a table or column name in MySQL' is the reference question for MySQL.
)
You have to test on everything you are going to support, so "all the database systems out there" is not in realty an option.
To be more realistic, you can decide which DBMS you want to support, and write a subset of SQL which they are all happy with, and test them with automated tests.
For example, you might consider:
MySQL
Postgres
MS SQL Server
Oracle
I believe these all support ANSI double-quotes for quoting names, so if you quote all names all the time then you have one less thing to worry about.
I'm working on implementing and designing my first database and have a lot of columns with names and addresses and the like.
It seems logical to place a CHECK constraint on these columns so that the DB only accepts values from an alphanumeric range (disallowing any special characters).
I am using MySQL which, as far as I can tell doesn't support user defined types, is there an easy way to do this?
It seems worth while to prevent bad data from entering the DB, but should this complex checking be offloaded to the application instead?
You can't do it with a CHECK constraint if you're using mysql (question is tagged wth mysql, so I presume this is the case) - mysql doesn't support check constraints. They are allowed in the syntax (to be compatible with DDL from other databases), but are otherwise ignored.
You could add a trigger to the table that fires on insert and update, that checks the data for compliance, but if you find a problem there's no way to raise an exception from a mysql stored proc.
I have used a workaround of hitting a table that doesn't exist, but has a name that conveys the meaning you want, eg
update invalid_characters set col1 = 1;
and hope that the person reading the "table invalid_characters does not exist" message gets the idea.
There are several settings that allows you to change how MySQL handles certain situation (but those aren't enough) for your case.
I would stick with data validation on application side but if you need validation on database side, you have two options:
CREATE PROCEDURE that would validate and insert data, do nothing or raise error by calling SIGNAL
CREATE TRIGGER ... BEFORE INSERT which would validate data and stop insert like suggested in this stackoverflow answer
I am working in a project where we are using SQL Server database currently. But recently a decision has been taken that the database will be changed to MySQL.
I am not using any stored procedures, views, triggers, user defined functions, etc. But I think even then some queries written for SQL Server will not be supported by MySQL.
Can anyone help: what are the things that I have to check (and change) so that all the queries will work properly for MySQL also?
Queries that I know without consulting the documentation that will not work:
(recursive) common table expressions
windowing functions
queries using the standard SQL string concatenation ||
UPDATEs with JOIN are different between the two systems
Date arithmetics: date_column + 1 behaves differently in SQL Server
Division by zero will produce an error
SQL Server will reject values that do not fit into a column (instead of silently truncating it, which MySQL does in the default installation)
DDL that will not work and might have an impact on performance and/or data quality
datetime columns where you need precision up to milliseconds
tables with check constraints
indexed views
triggers on views
table functions (select * from my_function(42);)
filtered indexes ("partial index")
function based indexes
There's always the option to take commercial support from MySQL AB for this problem. I'm pretty sure they've done enough MSSQL->MySQL migrations to know alot about that. If a price tag on the migration is not a problem.
Alternatively, you could try to run the MySQL Migration Toolkit over the data and look for meaningful error messages at the stuff it cannot migrate. MySQL Migration Toolkit is part of the MySQL GUI Tools.