2

Recently we had a discussion if rough DB schema (high level tables and columns) design should be part of system design phase or not.

We have two confronting approaches in the company. Let's assume System Design consists of designing Queues, Lambdas, integration with other microservices, etc.

Approach 1) In system design we should also include (at least in rough idea) what tables should be in DB, with relations, and normalization.

Approach 2) During system design we should just state that DB is there, and that's it. Later DB schema will naturally evolve after logic is implemented and needs to be persisted.

What do you think?

New contributor
Maciej Pszczolinski is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
4

It is never wrong to have a rough idea of what your goals are, at any stage of design, as long as it is a rough idea, a concept on a piece of paper, nothing written in stone. You could also envision certain tables and attributes if it helps you to get a clearer picture. But make sure everyone in the team takes this of what it is: it is not a blueprint of what must be build afterwards.

When it comes to table design with attributes, relations and normalization, it is a good idea of only implementing exactly the pieces you need for the current iteration at your database, for supporting the persistence required for the use case or user story you are planning for your next release, and nothing more, and nothing just because you had in your former concept.

Often it turns out that your former "vision" was roughly correct, but the details are quite different, so you will be happy that you don't have to fix too many of those differences at the implementation level.

1

I think a data model is an essential part of most designs. This means you have expressed the major entities and their relationships in the system you are designing. How is a real world problem and solution mapped to a computer program? You'll quickly fail when working in a team if you go into coding without having reached clarity on how you are going to solve the problem.

When I read database tables, columns, these are implementation artifacts. There is no need to write this all out. You note down there is a persistence layer needed.

There are couple exceptions. Sometimes the data structures are dictated by existing designs. Sometimes they are generic, like log files. In an exploratory design, the may not be enough information available. But they are never 'obvious' - any two developers will write vastly different implementations when it is 'obvious' ;-)

Your Answer

Maciej Pszczolinski is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.