2 ms·

Craig Kerstiens's advice/writings is usually pretty sound, but I think he makes a fairly significant mistake in providing the advice he does here: over generali

Craig Kerstiens's advice/writings is usually pretty sound, but I think he makes a fairly significant mistake in providing the advice he does here: over generalization. I appreciate he's talking about advice to beginners, but even so I think he needs to set context in his examples. Missing the context of possible solutions is probably the biggest mistake that anyone makes when making their choices in this (and many other) regard(s). None of the things mentioned are necessarily bad depending on context. For example, if I have a billion people per second visiting my website, yeah, storing the site images in PostgreSQL alongside the rest of the data probably isn't a great idea. But, if I am building an ERP system for the SMB market, it may be a fine idea given the degrees of concurrency I can expect, the cost of server equipment, and the advantages of keeping related data (binary or otherwise) together. The trade-offs are different. Simply put, it depends. I think this post could be improved with some clarification and I do think a tip sheet for beginner's is a good idea coming from someone that does have good advice for PostgreSQL... it just needs to be less generally prescriptive and more instructive about how to think about the given advice.

sbuttgereit 10y ago
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.

sbuttgereit 10y ago

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.