Hacker News Reader

Comment by dahauns | Hacker News Reader

This line raised a huge red flag for me:

"If the customer doesn’t have a fixed contract, it is assumed they are on a default contract"

No. Don't assume, specify. Explicitly.

If this is part of your specification, have a DefaultContract entity of some kind somewhere. And don't call this table just "Contracts", make it clear that those exist in addition to or overlay a default contract.

It might sound like overkill, but in my experience in business application development, one of the single largest and most painful sources of errors and refactoring headaches are implicit assumptions in the data model.

View on HN

> have a DefaultContract entity of some kind somewhere

This is the OO mindset described at the bottom - the odd compulsion to have a reified entity for every concept.

A lot of people have missed that the representation you persist doesn't have to match the representation you present. In this case, don't store default contracts, but present them e.g. via a database view.

But nothing of this has to do with OO. This is an argument at the relational level.

And yes, if there's something as fundamental a concept in the business model as a default contract that's in effect when no other contracts overrule it, then IMO it damn well should be represented explicitly in the persisted data model.

I didn't talk about the specific nature of the representation. The important part is that the intent of the data should be explicit - data lives longer than code.

I've seen far too many DB schemas leaning too hard on implicit assumptions and inferring information that lead to hard to understand data models, unnecessary complex (and hard to optimize) data access (no matter the paradigm), and well, lots of errors.

> If this is part of your specification, have a DefaultContract entity of some kind somewhere.

Yes, but not in the database table for contracts. That's how I read this part of the post. I would expect the assumption that if the customer doesn't have a fixed contract, they are on a default contract to be encoded in business logic somewhere in an application that uses this database.

> I would expect the assumption that if the customer doesn't have a fixed contract, they are on a default contract to be encoded in business logic somewhere in an application that uses this database.

That's exactly the kind of harmful assumption I'm talking about. Harmful in that when people act on that assumption and actually implement it that way.

How a default contract might be represented may vary, and of course it is in no way required or even sensible to be stored as a row in the contracts table.

But to think that it is such a fundamentally different kind of data that it should be represented apart from the rest, in a different system, in a different layer, in a completely different form of representation - this is where madness lies.

> How a default contract might be represented may vary, and of course it is in no way required or even sensible to be stored as a row in the contracts table.

But you're saying it does need to be represented somewhere in the database? That putting it anywhere else is harmful?

Can you elaborate? Why is it harmful?

> to think that it is such a fundamentally different kind of data that it should be represented apart from the rest, in a different system

The concept of a "contract" is a business logic concept to begin with. That concept is represented in the application already. How (or whether) the data associated with a particular contract is stored in the database is an implementation detail.

Yeah that's a lot to be said about being explicit. For example, what if even on a default contract you want to start tracking payment adherence, or maybe sales information and attributing them to sales' numbers.

Or maybe you start reporting and want reports on contracts vs default contracts.

And then things get messy. Because the real world gets messy.

Reply on news.ycombinator.com