Question

So, have the chance to do my first “real” database, just thinking to myself what I should think about… any suggestions?

• Select DB (using MySQL)
• Select DB engine based on needs (using MySQL, know MyISAM vs InnoDB)
• CREATE TABLE documention for DB using
• Column definition (select right datatype)
• Model data to be normalized
• Referential Integrity: Primary Key (Natural or Surrogate); Composite Keys; Foreign Key

Which leads me to my main question, how do I know if the database is a success at fit enough?

Answer 1

As you are listing general questions that need to be answered in order to go from idea to working system I’ll propose that it is very important to organize them into

1) logical design (get a clean model that represents the problem space you are trying to model)

2) physical design (which RDBMS and storage engine, exact data types, other practical and performance related decisions)

You are doing too much of mixing between the two. When you get a clean logical model and know the relationships between the entities you are modelling then the physical modelling will not be hard.

EDIT:
There are many books that deal with the steps of logical data design, but normally you would try to:

1. define use cases and business requirements (things are pretty soft still, check the requirements for contradictions; this is done interviewing people who know business process well, which can degenerate to a discussion with yourself)
2. get a list of all the attributes and entities used across the system and define them (data dictionary)
3. determine the domain of the attributes (which, later at physical level can be accomplished as data type, check contraint or by referring to ‘helper’ table, but don’t worry about this yet, just make sure that you define domains well)
4. draw ER/UML diagrams defining relationships – define tables in terms of primary keys, foreign keys and all other attributes (this time aim for a completeness); this step can be done using CAM and decent diagramming tools will spit out CREATE DATABASE scripts from diagrams
5. examine the model in search for denormalized data (should be normalized already, however when translating problem space into logical model it is possible to make mistakes and discover that you have redundancy or other anomalies)

A few of these steps need to go back and forth as you consider different ways of accomplishing certain tasks. For example including new attributes might make you go and analyze a new use case. Or a discovery of contradicting requirement might lead to a discovery of a whole new entity. Or discovering a redundancy might lead you to a discovery of undocumented process that exists (and justifies, or rather, explains percieved redundancy by redefining a seemingly duplicate attribute). Etc…