Thanks for the replys

@Toby Harman

I was thinking in something like that, but i must check some things before doing that.

My application main core works around this table, i have to do several query's against it, and that kind of schema, will increase the complexity...

@Craig Farrell

I know about normalization and the normal forms, but when i was developing the application and designing the database, kind of "on-the-fly", learning the business rules and developing/designing at the same time, i had to make some choices, and like i wrote above, to decrease the complexity of the querys i choose to put all into a big table, with all properties related to the product itself...

One of the queries that i need to do, it's to display the forecast of the load of the factory, in this query i need to check every product that isn't sent to factory, and check the state.

If it's created/defined i have some internal rules (predefined) that tells the max time that it can be in each department.

If it's in 2d modeling department, that department when accepts has to define when it will be ready to send to the next department and what department, and after that date i use the predefined values.

If it's in approval once again the department defines when it's ready, and the same above rule it's applied... and so on...

And one more thing, i forgot to tell, the product can skip some states, for example it can be sent from the 2D to 3D without passing for approval, or directly from 2D to the factory, and i need to handle this situations, in the actual table i just set the properties for the skipped state with default values, but once again i don't like this approach...

If all this info is in the same table it's a lot more easier to create the query...

So i need to come up with a solution that do all this, without making my query's extremely complicated and more or less flexible to increase or decrease the number of departments/states that the product can pass/have in the future.

Thanks