4 ms·

+1. When I started in the industry, it was common for more experienced developers to drill the “data outlives the application that generated it” principle into

+1. When I started in the industry, it was common for more experienced developers to drill the “data outlives the application that generated it” principle into you. Somewhere in the transition to NoSQL and back we lost this.

Pet_Ant 3y ago
The _data_ yes, the _database_ no. The data will get migrated to different solutions at different times. I've lost track of how often I've been porting MySQL to SQL Server, SQL Server to Postgres, Postgres to Mongo, Mongo to cloud etc. EDIT: fixed capitalization of "PostGres"
- winnebago 3y ago
  This really depends on the size of your data set. If you have a large database (TBs+) it's likely to be very long-lived due the effort/hardware resources a migration requires - especially if you want to improve the schema when migrating.
  - blowski 3y ago
    I’ve seen a database migration project outlive application rewrites, multiple changes in CTO, and the company being acquired.
- jhardy54 3y ago
  Friendly suggestion: the conventional capitalization is either Postgres or PostgreSQL.
SkyPuncher 3y ago
Context is key. If you have an established business or startup, data will outlive the application. However, you need a product that lives long enough for either data or application to matter. In the startup world, that means making decisions that help you ship now, at the expense of debt/costs down the road.
- mavelikara 3y ago
  IME, Foreign Keys do not slow down development velocity, after you factor out the upfront time investment it takes to understand them, normal forms, and other RDBMS concepts. Other posters in this thread have argued that they take CPU cycles during program execution - which is factual correct.
da_chicken 3y ago
It wasn't the transition to NoSQL. It was the transition to web APIs. Now the application that can access the database has a universal shim in place that deals with the messy business of taking requests and applying them to the data store. Now there's typically three applications that need DB access: 1. The application it was built for. 2. The read-only reporting and visualization tools. 3. The web API.

Pet_Ant 3y ago

The _data_ yes, the _database_ no. The data will get migrated to different solutions at different times. I've lost track of how often I've been porting MySQL to SQL Server, SQL Server to Postgres, Postgres to Mongo, Mongo to cloud etc. EDIT: fixed capitalization of "PostGres"

winnebago 3y ago
This really depends on the size of your data set. If you have a large database (TBs+) it's likely to be very long-lived due the effort/hardware resources a migration requires - especially if you want to improve the schema when migrating.
- blowski 3y ago
  I’ve seen a database migration project outlive application rewrites, multiple changes in CTO, and the company being acquired.
jhardy54 3y ago
Friendly suggestion: the conventional capitalization is either Postgres or PostgreSQL.

SkyPuncher 3y ago

Context is key. If you have an established business or startup, data will outlive the application. However, you need a product that lives long enough for either data or application to matter. In the startup world, that means making decisions that help you ship now, at the expense of debt/costs down the road.

mavelikara 3y ago
IME, Foreign Keys do not slow down development velocity, after you factor out the upfront time investment it takes to understand them, normal forms, and other RDBMS concepts. Other posters in this thread have argued that they take CPU cycles during program execution - which is factual correct.

da_chicken 3y ago

It wasn't the transition to NoSQL. It was the transition to web APIs. Now the application that can access the database has a universal shim in place that deals with the messy business of taking requests and applying them to the data store. Now there's typically three applications that need DB access: 1. The application it was built for. 2. The read-only reporting and visualization tools. 3. The web API.