Live data from Hacker News

Common data model mistakes made by startups

metabase.com

11–20 of 137 posts

Re: Common data model mistakes made by startups

#11

> Typically semi-structured data have schemas that are only enforced by convention Technically, in Postgres you can (kind of) enforce arbitrary schemas for semi-structured data using CHECK constraints. Unfortunately this isn't well-documented and NoSQL DBs often don't support similar mechanisms.

Seems likely that the enforced schema would then break things when someone updates the "live" schema without updating all of the checks littered through downstream tables...

Re: Common data model mistakes made by startups

#12

I think the biggest mistake some startups make wrt their data model is not really thinking about it at all. The data model winds up being the byproduct of all the features they've implemented and the framework and the libraries they've used, rather than something that was deliberately designed.

Oddly, I feel the opposite is also a trap. A carefully crafted data model often stalls out compared to a grown one.

Re: Common data model mistakes made by startups

#16

I think the biggest mistake some startups make wrt their data model is not really thinking about it at all. The data model winds up being the byproduct of all the features they've implemented and the framework and the libraries they've used, rather than something that was deliberately designed.

I think it’s a mistake that they don’t revisit it occasionally, and if necessary pull the trigger on a new schema + migration scripts.

Some early mistakes just can’t be solved without a do-over, and from a recent experience, it ends up being less work than maintaining a flawed schema.

Re: Common data model mistakes made by startups

#17
post #10

If your company has a subscription business model, keep a history of user's subscriptions. They change over time and it is likely you will need to measure popularity and profitability of product offerings over time. Please don't force your analytics team to rely on event logs to reconstruct a subscription history.

Stripe manages this extremely well

Re: Common data model mistakes made by startups

#18
post #10

If your company has a subscription business model, keep a history of user's subscriptions. They change over time and it is likely you will need to measure popularity and profitability of product offerings over time. Please don't force your analytics team to rely on event logs to reconstruct a subscription history.

This. You want to capture timestamps as users downgrade, upgrade, change quantity, churn, etc. If you have a status field, timestamp the changes to it. This way it’s easy to get the state of the world on any given day, which is a common analysis that’s done to study behavior of cohorts of subscriptions over time.

Re: Common data model mistakes made by startups

#19
post #4

Metabase provides business analytics, and this list of "common mistakes" is weighted towards "choices which get in the way of business analytics". For example: > 1. Polluting your database with test or fake data > [...] By polluting your database with test data, you’ve introduced a tax on all analytics (and internal tool building) at your company.

The end of this article is particularly weird. Is it really suggesting that a good general rule is to optimise for business metric queries (which sounds like something that would generally run daily during off peak hours or ad hoc when someone needs the data) over the most commonly run reads/updates (which sounds like something that will happen multiple times per minute for every active user)?

I feel like I'm missing something because that seems insane to me.

Post reply on HN