Database design for a transportation company

I am designing a database and I am just wondering if I am doing it correctly. I have tables for things like State with all the states in them and then I reference the ID in other tables. But should I just handle this in my UI and then store it as a string or is this the correct way?

The goal of this database is to handle day to day operations of a transportation company. This version of the database is only focused on handling People and contacts. We manage employees, drivers, and there positions in the company. We will be tracking things like accidents, and other incidents drivers have, and gain a better understanding of driver / employee turn over.

``
--
-- Database: hrm
--

-- --------------------------------------------------------

--
-- Table structure for table address
--

CREATE TABLE address (
address_id int(11) NOT NULL COMMENT 'Primary key for address rows.',
address_line_one varchar(60) NOT NULL COMMENT 'First street-address line.',
address_line_two varchar(60) DEFAULT NULL COMMENT 'Second street address line.',
city varchar(30) NOT NULL COMMENT 'Name of the city.',
state_id int(11) NOT NULL COMMENT 'Foreign key to state table.',
postal_code varchar(15) NOT NULL COMMENT 'Postal code for the street address.',
modified_date datetime NOT NULL COMMENT 'Date and time the row was last updated.'
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

-- --------------------------------------------------------

--
-- Table structure for table contact
--

CREATE TABLE contact (
contact_id int(11) NOT NULL COMMENT 'Primary key for contact rows.',
title varchar(8) DEFAULT NULL COMMENT 'A courtesy title. For example, Mr. or Ms.',
first_name varchar(50) NOT NULL COMMENT 'First name of the person.',
middle_name varchar(50) DEFAULT NULL COMMENT 'Middle name or middle initial of the person.',
last_name varchar(50) NOT NULL COMMENT 'Last name of the person.',
suffix` varchar(10) DEFAULT NULL COMMENT 'Surname suffix. For ex

latin1 in this day and age? You probably have a plan to deal with names that aren't in that character set? The whole split between first, middle and last name also might conflict with the real world. (I guess the names argument is a bit overkill, but you could possibly also get away with a single generic "name" field.)

A few tables are really hidden enumerations - you could think about using something on the application level rather than requiring yet another join on every operation (or use MySQL enumerations which are rather unwieldy though). Edit: That's basically the answer to your first question, i.e. I'd probably go with the actual string value if you don't need to associate more information with the enumeration.

The user table has the column password. That has to be a password hash (meaning the field will have a lower fixed length) and should consequently be named password_hash or something similar.

Lacking the exact requirements I still find the upload table a bit weird - why are size and type of type varchar(200)? Both sound way more restricted in scope and size more like it should be an integer type instead.

StackExchange Code Review Q#128303, answer score: 2