Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Common data model mistakes made by startups

metabase.com

Post reply on HN
Print view View original

31–40 of 137 posts

Re: Common data model mistakes made by startups

#31

Post by beachy »

pyrophane wrote: post #6

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.

At the other end of the scale is a data model designed for extreme extensibility.

If you ever hear anyone bragging that their data model is entirely metadata driven, and can be used to model anything - without changing the database - that's a huge red flag, as is looking in and seeing tables called "element", "business object" and the like.

Unfortunately, for most serious Enterprise systems, a degree of flexibility is essential. It's being able to pick the right balance between hard coding first class domain objects into the database and allowing for extensibility that IMO marks the truly expert system designer.

Re: Common data model mistakes made by startups

#32

Post by allie1 »

vosper wrote: post #24
allie1 wrote: post #16

Earlier quoted context omitted.

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.

This is the place I work at. The data model was designed with a narrow focus. When that turned out to not be viable, the company moved into an adjacent and much larger market. But the names never changed, and the subtle differences between the two worlds was never addressed. So now our application is full of terminology and restrictions that confuse our customers, and our database doesn’t match anyone’s mental model…

I hear ya. Both would probably cost the same, rebuild probably more, today, but it’s still cheaper in the long run. Unless the business goes back to what it was, it will keep diverging from the current terminology. No manager wants to hear it, but taking a 3-6 month breather to address tech debt like this is worth its weight in gold.

Re: Common data model mistakes made by startups

#33

Post by duped »

pyrophane wrote: post #6

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.

Practically speaking the data model creates very little value. If your startup is trying to make money, features are more important than design for a good stretch.

There comes a time to refactor and fix your architecture but it's usually not at the beginning.

You can design a data model if you don't know what you're building. And no startup really knows what they're building.

Re: Common data model mistakes made by startups

#34

Post by FigmentEngine »

rm999 wrote: post #30
watermelon0 wrote: post #29

Earlier quoted context omitted.

Hard deletes most likely need to be supported, due to legal or contractual obligations. Designing with this in mind, makes everything a lot easier in the long run.

I’ve always NULL’d values, not deleted rows. E.g. GDPR request? NULL out all identifying information, but keep the record. As long as your primary key has no business meaning you should never have to delete the row of a table.

INAL, but... you might want to revisit that code. article 17, right to erasure is about erasure of personal data, not about making non-indentifiable. of course they dont define erase or delete :-)

(edit: typo)

Re: Common data model mistakes made by startups

#35

Post by Aperocky »

FigmentEngine wrote: post #34
rm999 wrote: post #30

Earlier quoted context omitted.

I’ve always NULL’d values, not deleted rows. E.g. GDPR request? NULL out all identifying information, but keep the record. As long as your primary key has no business meaning you should never have to delete the row of a table.

INAL, but... you might want to revisit that code. article 17, right to erasure is about erasure of personal data, not about making non-indentifiable. of course they dont define erase or delete :-) (edit: typo)

well to me the transaction is the same as deleting a record and populating a NULL record.

I don't see why the law should care in any way about a company populating NULL records.

Re: Common data model mistakes made by startups

#36

Post by giovannibonetti »

> Queries for business metrics are usually scattered, written by many people, and generally much less controlled. So do what you can to make it easy for your business to get the metrics it needs to make better decisions.

A simple but useful thing is setting the database default time zone match the one where most of your team is (instead of UTC). This reduces the chance your metrics are wrong because you forgot to set the time zone when extracting the date of a timestamp.

Re: Common data model mistakes made by startups

#37

Post by FigmentEngine »

Aperocky wrote: post #35
FigmentEngine wrote: post #34

Earlier quoted context omitted.

INAL, but... you might want to revisit that code. article 17, right to erasure is about erasure of personal data, not about making non-indentifiable. of course they dont define erase or delete :-) (edit: typo)

well to me the transaction is the same as deleting a record and populating a NULL record. I don't see why the law should care in any way about a company populating NULL records.

"NULL out all identifying information" is anonymization, not deleting the information.

Re: Common data model mistakes made by startups

#38

Post by sethammons »

giovannibonetti wrote: post #36

> Queries for business metrics are usually scattered, written by many people, and generally much less controlled. So do what you can to make it easy for your business to get the metrics it needs to make better decisions. A simple but useful thing is setting the database default time zone match the one where most of your team is (instead of UTC). This reduces the chance your metrics are wrong because you forgot to set…

We went this route and ended up with a db set to pst and some servers based on Chicago time. Endless time bugs. Pick one timezone for everything or just use unix timestamps.

Re: Common data model mistakes made by startups

#39

Post by xyzzy_plugh »

giovannibonetti wrote: post #36

> Queries for business metrics are usually scattered, written by many people, and generally much less controlled. So do what you can to make it easy for your business to get the metrics it needs to make better decisions. A simple but useful thing is setting the database default time zone match the one where most of your team is (instead of UTC). This reduces the chance your metrics are wrong because you forgot to set…

I cannot overstate how bad this advice is. Everything should be UTC by default. You can explicitly use timestamp with timezones and frankly it's trivial to query something like midnight-to-midnight PST. Your team should learn this as early as possible.

Build tooling around this, warn users, hell, educate them, but don't set up foot-guns like non-UTC.

If I see a timestamp without a timezone, it must always be UTC. To do anything else is to introduce insanity.

Re: Common data model mistakes made by startups

#40

Post by dehrmann »

giovannibonetti wrote: post #36

> Queries for business metrics are usually scattered, written by many people, and generally much less controlled. So do what you can to make it easy for your business to get the metrics it needs to make better decisions. A simple but useful thing is setting the database default time zone match the one where most of your team is (instead of UTC). This reduces the chance your metrics are wrong because you forgot to set…

I disagree on this because handling DST is error-prone.
Post reply on HN