3 ms·
Hi, Files: I Agree, storing entire files in databases (or at least the same databases as common field data is a horrible concept, but paths to files can and sh
by lewiscowles1 14y ago
Hi,
Files: I Agree, storing entire files in databases (or at least the same databases as common field data is a horrible concept, but paths to files can and should be stored to files to prevent "searching" to locate files, check modification dates, sort by alternative, compute once(or as few times as possible), store forever data, so that files can be easily located and just a check to see if they exist.
DB Procedures being a poor design practice: I disagree completely, it is merely a separation of logic. Triggers, can be a bit much, but procedures can help, especially when used correctly for the right use-cases. Just as True that a good programmer / engineer should never aim to go for one method or another, but get the right tool for the Job.
DB Hammer, Programming Hammer, Buzz-word Hammer, all pet hates of mine, I have spent the last decade learning what I do know exceptionally well, I dislike hammer lovers on most levels and often find that the structures they build show their level of workmanship.
Provocative article, Nice work!
- programminggeek 14y agoYour point that DB Procedures as a separation of logic being a reasonable choice I think boils down as much to your criteria of a reasonable choice. Good design is about understanding your priorities and how they affect the outcome. For example, if I prioritize tests and testability higher than just shipping code, then I will very like care a lot about where my logic lives and if I can test it. If I just care about shipping code, where my logic lives and how I test it is less important than a working product. Well informed tradeoffs are often reasonable choices.