Common data model mistakes made by startups

Post by stouset » Sun, May 23, 2021, 12:29 AM UTC

quietbritishjim wrote: post #45

irrational wrote: post #28

Earlier quoted context omitted.

> if that table's primary key is a foreign key in another table - imagine deleting a user and then having no idea who made an order Assuming you have constraints set up correctly (on delete no action or on delete restrict) then how could this ever happen? If you don’t have constraints set up correctly…

That would just make the data loss problem worse still. I realise OP just chose an arbitrary example, but if you really are talking about users and orders, and if you delete a user, then really deleting the records for their associated orders is even worse than losing track of who made them.

Post by tomnipotent » Sun, May 23, 2021, 1:05 AM UTC

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.

Post by jerrysievert » Sun, May 23, 2021, 1:36 AM UTC

allie1 wrote: post #15

Pxtl wrote: post #13

How do you reconcile the first bullet point (polluting data with test data) vs Test In Production being the modern trend? Those sound irreconcilable.

Include a cleanup step after each test?

Post by irrational » Sun, May 23, 2021, 1:46 AM UTC

quietbritishjim wrote: post #45

irrational wrote: post #28

Earlier quoted context omitted.

> if that table's primary key is a foreign key in another table - imagine deleting a user and then having no idea who made an order Assuming you have constraints set up correctly (on delete no action or on delete restrict) then how could this ever happen? If you don’t have constraints set up correctly…

That would just make the data loss problem worse still. I realise OP just chose an arbitrary example, but if you really are talking about users and orders, and if you delete a user, then really deleting the records for their associated orders is even worse than losing track of who made them.

Post by jhgb » Sun, May 23, 2021, 2:06 AM UTC

inopinatus wrote: post #51

rm999 wrote: post #23

>Soft deletes This section is totally wrong IMO. What is the alternative? "Hard" deleting records from a table is usually a bad idea (unless it is for legal reasons), especially if that table's primary key is a foreign key in another table - imagine deleting a user and then having no idea who made an order. Setting a deleted/inactive flag is by far the least of two evils. >when multiplied across all the analytics que…

Most order forms are snapshots of data at the instant of their lodgement, since they are sales contracts. It is a rookie blunder to link them relationally to master data for products and PII &c. The record of an order is not intrinsically PII and thereby subject to rights of erasure. It may well be equally unlawful in some jurisdictions to irrevocably destroy it entire, it being necessary for accounting or tax audit,…