advice on database design - mysql

Question

I am building a database for my website. I have a schema here : enrolin.in/download.png
Introduction to website:
It collects data from students on behalf of colleges.
Now what I have done in database is that I have created a UDT-where data that is fixed to a student is stored. and CST-where data that can change with every new course is stored.
I am very new to database design, so please have a look at the database design and advice me where i can improve. I want it to be perfect so that there are no complications/limitations with database in future
NOTES:
There is not just for one college. It is like a platform where different colleges can add their courses. Every college has different courses with different subjects etc. There can be many CST's, may be a separate CST for every new course. Plus I am not sure about the way I am storing course data , I mean CST and UDT. Every college will have access to the data of students which have applied for a course under that college and every student will have access to data to his previously filled form data,status etc.
Thanks in advance. If anything is unclear, please ask in comments.
Update : -- tables
-- Table CST
CREATE TABLE CST (
cst_id int NOT NULL ,
rollno int NOT NULL ,
semester int NOT NULL ,
CONSTRAINT CST_pk PRIMARY KEY (cst_id)
);
-- Table UDT
CREATE TABLE UDT (
udt_id int NOT NULL ,
id int NOT NULL ,
name varchar(255) NOT NULL ,
gender varchar(255) NOT NULL ,
fatherame varchar(255) NOT NULL ,
mothername varchar(255) NOT NULL ,
dob date NOT NULL ,
signature binary(255) NOT NULL ,
CONSTRAINT UDT_pk PRIMARY KEY (udt_id)
);
-- Table address
CREATE TABLE address (
address_id int NOT NULL ,
id int NOT NULL ,
add_name varchar(255) NOT NULL ,
add_street varchar(255) NOT NULL ,
city varchar(255) NOT NULL ,
state varchar(255) NOT NULL ,
country varchar(255) NOT NULL ,
pin int NOT NULL ,
CONSTRAINT address_pk PRIMARY KEY (address_id)
);
-- Table courses
CREATE TABLE courses (
course_id int NOT NULL ,
course_name varchar(255) NOT NULL ,
CONSTRAINT courses_pk PRIMARY KEY (course_id)
);
-- Table phones
CREATE TABLE phones (
phone_id int NOT NULL ,
id int NOT NULL ,
phone int NOT NULL ,
CONSTRAINT phones_pk PRIMARY KEY (phone_id)
);
-- Table photos
CREATE TABLE photos (
photo_id int NOT NULL ,
id int NOT NULL ,
photo binary(255) NOT NULL ,
CONSTRAINT photos_pk PRIMARY KEY (photo_id)
);
-- Table sub_trans
CREATE TABLE sub_trans (
sub_trans_id int NOT NULL ,
transactions_t_id int NOT NULL ,
subjects_sub_id int NOT NULL ,
CONSTRAINT sub_trans_pk PRIMARY KEY (sub_trans_id)
);
-- Table subjects
CREATE TABLE subjects (
sub_id int NOT NULL ,
course_id int NOT NULL ,
subjectname varchar(255) NOT NULL ,
CONSTRAINT subjects_pk PRIMARY KEY (sub_id)
);
-- Table transactions
CREATE TABLE transactions (
t_id int NOT NULL ,
id int NOT NULL ,
course_id int NOT NULL ,
p_status int NOT NULL DEFAULT 0 ,
phones_phone_id int NOT NULL ,
UDT_udt_id int NOT NULL ,
photos_photo_id int NOT NULL ,
address_address_id int NOT NULL ,
CST_cst_id int NOT NULL ,
CONSTRAINT transactions_pk PRIMARY KEY (t_id)
);
-- Table users
CREATE TABLE users (
id int NOT NULL ,
name varchar(255) NOT NULL ,
email varchar(255) NOT NULL ,
password int NOT NULL ,
CONSTRAINT users_pk PRIMARY KEY (id)
);
`

Answer 1

UDT:
Typo fathername. UDT has an FK to what? Users? Slim down the varchar size in UDT. Sure you want a single column for name? Ok, at least document that you chose to not have more than 2 parents. Otherwise you need another table.
Users:
Passwords run thru a hash function won't be ints and user needs a Salt for optimal security. Imho.
awaiting more clarification below
There is zero purpose of UDT and users both existing. Pick one, pickup lost fields from one you are ditching.
Even hypothetically if it wasn't 1:1 name would denomalize the database.
phones:
Your columns for phones need to be described. Also can a user have more than 1 phone (if so, phoneType varchar(10) or int code? )
Also I would go like varchar(30) on phone value not an int.
Addresses:
Same deal as phones. Can a user have more than one? PostalCode pin should be varchar
Transactions:
This seems to be the hub of your schema. All of your transactions hinge on FKs to data that may have subsequently changed. I see RISK in that. Older transaction could get skewed results for lookups. There are easy ways to fix this issue if you even see it as one. Same goes for courses. What if History 101's id stays the same but next semester that id is Early Roman Empire? Just things to think about.
Lastly the documented tables have no FK relationships shown.