3 ms·

I see it the other way around. Code is fluid, data persists. So I would expect more rigor in the design of the schema then anywhere in the code. And hopefully w

by yokaze 6y ago

I see it the other way around. Code is fluid, data persists. So I would expect more rigor in the design of the schema then anywhere in the code. And hopefully with some fore-sight, you won't have to change it every other day. Migrating the data requires also some reflection. No amount of work of coding will fix your data, if it is a mountain of inconsistent garbage.

smashah 6y ago
I guess with experience comes the ability to correctly design the schema from day one. The project was just getting off the ground so schema was evolving constantly. If only there was such a thing as pgconfig.json which allows me to configure how strict I want the db to be - a sliding scale between NoSQL to SQL.
- yokaze 6y ago
  No one gets the schema right from the beginning. Waterfall is out of fashion for a reason. And there are schema migration frameworks out there for that purpose. If you care for the data you store, you'll have to take care of your data. ACID and the "rigidness" of schemata are tools for that, and to keep the complexity in check. It is much easier than accruing technical debt by having unstructured data and having later to figure out to make heads and tails of what you and your colleagues did at some arbitrary earlier time. (Not that crappy SQL designs don't have that problem). If you don't care for your data, as you are in the beginning, why don't you create the DB then from scratch? You can use various editors to create the schemata from tools you are more comfortable with. Don't work against the tool, and find the slider in your head to adjust your way of working.
  - lowwave 6y ago
    I strongly disagree with this. Getting the schema right, reduces code writing and code maintenance.
- neurostimulant 6y ago
  This is already solved in most server-side frameworks by using a schema migration tool. Heck, even wordpress has an easy way to automatically update a table's schema. The development of these tools in nodejs land are probably stalled due to nodejs community's obsession with nosql databases, but I bet there are several solutions available right now to handle this task.

by yokaze 6y ago

smashah 6y ago

I guess with experience comes the ability to correctly design the schema from day one. The project was just getting off the ground so schema was evolving constantly. If only there was such a thing as pgconfig.json which allows me to configure how strict I want the db to be - a sliding scale between NoSQL to SQL.

yokaze 6y ago
No one gets the schema right from the beginning. Waterfall is out of fashion for a reason. And there are schema migration frameworks out there for that purpose. If you care for the data you store, you'll have to take care of your data. ACID and the "rigidness" of schemata are tools for that, and to keep the complexity in check. It is much easier than accruing technical debt by having unstructured data and having later to figure out to make heads and tails of what you and your colleagues did at some arbitrary earlier time. (Not that crappy SQL designs don't have that problem). If you don't care for your data, as you are in the beginning, why don't you create the DB then from scratch? You can use various editors to create the schemata from tools you are more comfortable with. Don't work against the tool, and find the slider in your head to adjust your way of working.
- lowwave 6y ago
  I strongly disagree with this. Getting the schema right, reduces code writing and code maintenance.
neurostimulant 6y ago
This is already solved in most server-side frameworks by using a schema migration tool. Heck, even wordpress has an easy way to automatically update a table's schema. The development of these tools in nodejs land are probably stalled due to nodejs community's obsession with nosql databases, but I bet there are several solutions available right now to handle this task.