What is a database?

A database is defined as a collection of data, structured and stored in a computer system electronically. The database has to be controlled by a database management system. When we say a database management system then this should refer to both data and DBMS applications most of the time shortened to just a database.

Data is keyed in the form of rows and columns in a tabular form to make the manipulation of data much more efficient. Any data in a database can easily be accessed, controlled, updated easily, and managed to suit the needs of the organization using programs such as structured query language (SQL) for data querying. 

What is database software?

Database software is a program that is used to:

• Create and edit files
• maintain files and records of the database
• Data entry and editing
• Updating, and reporting

The database software also handles data storage, Security, Backup, reporting, and multi-access control.

In today’s world, strong database security is important as data theft has become more rampant. Database software has a graphical user interface to make data management simpler by enabling users to store data in a structured form. It's easier to access data. It allows users to build their own databases.

What comes first? Is it the database or it is the analysis of the problems to be solved? Is it possible to know what has to go into a database until we know what the software will do for us in solving the problem? I hold the opinion that a database should come after looking at the problem that is intended to be solved, and how to solve it.

Database Front end developers

Many practicing developers don't see themselves as "front-end" developers per see. They stay in their comfort zones. My call would be, to consider designing the API first which is the first interface with the "front-end".

Most developers  have different approaches to this issue. To me I have come to the conclusion that a better approach would lie in firstly, prototyping the front-end, using tools like Adobe XD, so that full validation of the client's requirements can be fully vetted and put into a test and analysis. This makes the other layers become clear.

When starting a new project it is necessary to also consider the data and begin with an ER diagram to help one figure from there and perhaps even build a prototype to ensure domain knowledge is captured.

Other practicing developers augur that this procedure is exactly the opposite of the way they work because, some would say, at that point they are not sure if at all they will need to use a SQL database when they start writing the code and hence no need for an ERD.

Database project Start-up process

Some would say that Different projects require different start up processes.

But I strongly disagree with this overview because I haven't seen the need for old style RUP  which is basically described above in many years today unless one works on completely different systems than what I have been engaged in personally. I no longer use big up-front designs.

Even though it sounds like an indicator that the cost of structural database change is high, I was taught to do data analysis first and yes the cost could be extremely high.

Entity relationship Diagram

Here's a typical ERD for a production monolith and a challenge to you to try to change it quickly.

I remember hearing my database lecturer quoting, "the word database has no plural". My reflex reaction was that something must be wrong with that. I hadn't even seen an IRL database but the point is you have to figure out the domain model first, what you are solving and not the schemas.

Personally I model the domain, but by doing that, I don't need an actual model, rather I will just need to know the domain to know what the model looks like. Lately, I've been engaged with working with very modular systems that don't use a shared database, so there is no "data model."

When to do logical data model

I don't do a logical data model but model the domain, implement as small modules that keep track of its own data. The keyword here is "small." What's the point of modeling a single table? My systems minimize the flow of data to zero if possible. There is no copying nor data value chain. Ask the component that has the data to do the work for you. This thinking is at the center of DDD.

Also, in general, the data doesn't interest me much. I'm more interested in behavior. You can infer the quality of the data from the behavior more often than not. On a light note, many will say it’s a Useless discussion. It’s like the question: What’s more important? Brain, heart, lung or stomach. You need all of them at the same time if you go into production. People will create mock-ups, DB guys create ER diagrams. So where is the problem?

Let's keep the discussion and your views in the comment section below!