Actually, thinking about it, I think the biggest database beginner mistake I see is simply not coming to grips with what the data actually means. The project I

Actually, thinking about it, I think the biggest database beginner mistake I see is simply not coming to grips with what the data actually means. The project I'm working on right now is a do-over project that exists because the original project team didn't take the time to really understand why they were doing the project, why the project mattered to the client; they simply saw, "it needs to do 'x', it needs to do 'y'". The client, in turn, simply took it for granted that the project team understood problem. At the end: it resulted in irrecoverably bad data collection. If you fail to understand the meaning in data and just try to jam values into some persistence store to get through some transaction someone told you to code up, you'll likely make decisions for the future that you don't even know will come yet. Each table, each value, expresses some idea, some piece of information that, without even considering the application functionality, has meaning in the context of the rest of the data you're capturing. If you respect that relationship of ideas, you'll know whether or not normalization or de-normalization makes sense, you will more likely have a flexible information architecture rather than a brittle one. So there's my beginner's advice: really understand what and why you are stuffing data into a database in the first place. Don't loose sight of the larger context. Conceptualize the information as information. Then figure out how the technology facilitates (or doesn't) the expression of that information with the greatest clarity.