4 ms·

The main thing i learned in my first production db work is that you pay for every bit of complexity you introduce. As a noob you are somehow much more afraid to

The main thing i learned in my first production db work is that you pay for every bit of complexity you introduce. As a noob you are somehow much more afraid to not "model the data right" so you tend to create much to many tables much to many n to m relationships you make everything a string a uuid a relationship, never use bools etc. But then you have to iterate and live with those systems and then you pay and every bit of complexity makes everything harder. To give you some simple examples: 1. We don't want to delete old data so we just use a "deleted" column and do that instead. Now every single time you have to filter out those results. 2. You just made this thing a relationship now every time you have to join. In the end, if you can keep it simple even if you don't model the data "perfectly". But of course sometimes the complexity is really necessary. To know when is being a good Backend / Db Engineer.

epr 5y ago
> 1. We don't want to delete old data so we just use a "deleted" column and do that instead. Now every single time you have to filter out those results. 2. You just made this thing a relationship now every time you have to join. Whether or not these were good decisions depends on the use cases of course, but papering over db implementation details like this with a view is pretty straightforward, no?
bob1029 5y ago
This is the whole point of the database: model the data exactly the way the business needs it, so you can have easy 1:1 conversations. Then, build some convenience views or other mapping layers on top of this data for use in reporting systems, etc. Don't screw up the physical tables just because you don't like the knowledge that they contain in certain contexts. Facts are facts. If you don't like what you are seeing, change your query or filter the result set. If a customer record needs to be retained after deletion per biz requirements, then an IsDeleted fact is 100% the right path. Both of your points enumerated above are trivially solved with views.

epr 5y ago

> 1. We don't want to delete old data so we just use a "deleted" column and do that instead. Now every single time you have to filter out those results. 2. You just made this thing a relationship now every time you have to join. Whether or not these were good decisions depends on the use cases of course, but papering over db implementation details like this with a view is pretty straightforward, no?

bob1029 5y ago

This is the whole point of the database: model the data exactly the way the business needs it, so you can have easy 1:1 conversations. Then, build some convenience views or other mapping layers on top of this data for use in reporting systems, etc. Don't screw up the physical tables just because you don't like the knowledge that they contain in certain contexts. Facts are facts. If you don't like what you are seeing, change your query or filter the result set. If a customer record needs to be retained after deletion per biz requirements, then an IsDeleted fact is 100% the right path. Both of your points enumerated above are trivially solved with views.