This makes systems using a model view controller architecture much simpler to maintain, as locating the code relevant to specific logic is significantly easier. Additionally, it makes expansion of systems much less complex, as it avoids the ‘feature cascade’ effect in which the addition of a single feature will result in a knock on or butterfly effect throughout the entire system.

The parts of a model view controller system are referred to as models, views and controllers, which makes perfect sense. The definition of these system parts is also quite intuitive.

• Views – Views are entirely for the presentation part of your application. It contains no brains, no logic, no intelligence to the extent permissible by the programming language used. A view is merely the appearance of your application and nothing else.
• Controllers – A controller handles feedback from the user and logic specific to the application. A controllers job is to receive input from a user, via controls found on the user interface of a view, to process it, communicating with a model if necessary, and then to send output to the user, usually by populating a view with relevant content.
• Models – Models perform business logic. Business logic, in this case, refers to items that are fundamental to the overall system design. For example, if a library application was constructed, the logic which ensured a library card owner only rented up to 5 books at a time, would be part of a model. Again, as part of the business logic, models also tend to control access to application storage, such as database(s), performing CRUD (creation, updating and deletion) tasks on the stored data.

I hope this helps explain the basics of the model view controller software architecture.

If you have any improvements or additions to these definitions or just want to discuss software architectures in general, feel free to use the comments section below.

The latest MySQL documentation (5.5) discretly mentions the fact these constraints are unfortunately not supported.

• The CONSTRAINT_TYPE value can be UNIQUE, PRIMARY KEY, or FOREIGN KEY.
• The UNIQUE and PRIMARY KEY information is about the same as what you get from the Key_name field in the output from SHOW INDEX when the Non_unique field is 0.
• The CONSTRAINT_TYPE column can contain one of these values: UNIQUE, PRIMARY KEY, FOREIGN KEY, CHECK. This is a CHAR (not ENUM) column. The CHECK value is not available until we support CHECK.

Take special note of the final line I’ve emboldened. This is quite a shame that this constraint type is not fully supported yet.

Apologies to readers for the implication that this was functional in my previous post, and thanks to the poster of this comment for noticing the discrepancy.

Check constraints, of course, function fine in many other DBMSs, and to that end, the original post on SQL check constraints is still relevant, but sadly not if you are worked with MySQL.

You can create a table with a check constraint in MySQL as follows. The check in this example disallows values of the ‘P_Id’ field from falling outside of the condition ‘P_Id>0′. In other words, the ‘P_Id’ field’s values must almost be greater than zero in order for the data to be accepted into the table by the database management system (DBMS).

CREATE TABLE Persons
(
P_Id int NOT NULL,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Address varchar(255),
City varchar(255),
CHECK (P_Id>0)
)

You are probably wondering how to add a constraint to an existing database table. This is quite easy, and uses an ‘ALTER TABLE’ SQL query. See the following example for how to add a check constraint to one of your existing database tables.

ALTER TABLE Persons
ADD CHECK (P_Id>0)

For more information, there are other highly useful example queries relating to SQL check constraints at the relevant SQL check constraint article on W3schools.