4 ms·
I'd add tagging, for anything that could conceivably use it, when you're doing DB design. May as well start with support, even if the functionality's initially
by corrral 4y ago
I'd add tagging, for anything that could conceivably use it, when you're doing DB design. May as well start with support, even if the functionality's initially dormant. Someone will ask for it, directly or indirectly, and it won't take long before they do.
- JohnBooty 4y agoI personally would not agree. But... your experiences are also real and I believe you when you say that your experiences DO support your conclusion. :) The "soft delete" design decision is usually pretty impactful and is in my experience potentially much more of a pain in the butt to implement later if you haven't included it from day 0. Audit trails and soft-deletes are also crazy useful for developers (both for debugging and for general cover-thine-ass utility) even if end users never touch them. Whereas, tags are easier to tack on later and are not intrinsically useful to developers.
- deleted 4y ago[deleted]
- dgb23 4y agoI agree. But if you’re asked to implement hierarchical categories, you implement them as tags underneath. This doesn’t cost you any time. When eventually they realize that categories don’t work (they never do) you can just turn a switch.