Vs Db Design Class Design (ER-Diagram)

Question

At the design stage of system development, if the design of the class dictates the design of db, or if the design of db dictates the design of the class. I understand that there are several situations where one or the other already exists and another has to be developed around the existing one. But tell me, can you start from scratch, which is the best approach? At first I am more inclined to Class Design, then DB, but I would like to contribute to this idea. What scaling issues should be considered? Problems with implementation?

Answer 1

Whenever it is, I almost always start with developing a database.

If you have a wrong or poorly designed program, you can always in the worst case throw this program and overwrite it. But if you have an incorrect or poorly designed database, by the time you realize that you have a problem, there may be hundreds of programs using this database. Changing the database means at least learning about each program used, and major changes to the design of the database can mean a significant modification to every program that uses the database. Therefore, it is more important for your database to be well thought out than for a well thought out program.

Answer 2

Depends on the application, I would say. If your application is highly data oriented, you should use an application design database; if your application is mainly related to business logic or computing, you probably want to support the design of the application.

Another consideration is the durability and availability of the application — as Jay says, it’s not uncommon for multiple applications to use the same database. Although I would suggest that this is the basis for providing a database interface based on a service or messages - I do not think that you want to allow several applications to have direct access to data. In this case, I think you focused on the level of service.

You might also consider comparing design with a business domain - ideally, you want your software to reflect business concepts (see Evans' Domain Managed Project). This is usually - but not always - easier when working with object technology, rather than with essential relationships (the classic question is how to inherit from a database model).

Finally, it is important to consider the team’s skills and inclination — having a team of database guru developers, an object model usually leads to a steep learning curve (and vice versa).

Answer 3

If the class design is dictated by the db design, or the db design is dictated by the class design.

I'm not sure I should dictate the design of another. A dictate implies a hard bond, which is usually bad.

The design of the database assumes that other programs will access the database. An important part of database design is the selection of good table names, column names, and integrity constraints. All of this is part of the overall database interface. (All these things are also related to normalization, a mathematical process that does not require application development. This is observation, not criticism.)

Indeed, it is very expensive to change a poorly designed public interface.

Answer 4

Your database should be well thought out, but neither the application nor the database design should greatly influence the other. Your applications should be agnostic. To store application data, you must rely on a layer that provides the necessary translations from your domain objects to database tables.