mysql - What is a better way to set up a database for an app? Normalized vs real world -

consider, please setup database backed application. ( in case db mysql , app in ruby ( rails 3), don't think matters question)

let's have app warehouse.

i have multiple items have categories , statuses.

for example table has parts have few statuses such as: in stock, discontinued, backordered , multiple categories, such as: hardware, automotive, medical, etc.

also have other tables need statuses , categories, such vendor: approved, out of business, new order: open, processes, shipped, canceled.

etc.

here question:

i think if wanted normalize db - have table called categories, categories_types, statuses, statuses_types.

then store categories in table, , category of type, such categories of parts, have foreign key category_type - parts, , on. same types.

this normalized way.

however see people create separate tables specific categories, example, there table called part_categories, vendor_categories, order_statuses, part_status. less normalized db, guess when dealing lot of tables, might clearer.

which of approaches better one? cons & pros in experience? go first setup, see second 1 i'm beginning doubt approach.

thank you.

in experience, tables of enumerated names invariably evolve own full-fledged model eventually. typically, begins adding boolean flags, or mentioned in answer above, referent types or valid date ranges.

from relational perspective, neither approach - putting status enums in 1 table, or breaking them separate tables - "more" normalized other. type-theoretic standpoint, makes more sense put part_categories , vendor_categories in own separate tables, no other reason requires no code in model make sure don't accidentally associate vendor category part.

if end putting them in same table, rails has nice feature called polymorphic associations automate type , id columns you. it's reasonable compromise between 2 approaches.

most importantly, contend enums take on model life of own, in case have messy job of finding of them in various tables, , recasting them in own table. tables cheap; why frugal them?