4 ms·

Good applications tend to get the database right first - since you can always re-write the mid-tier code relatively easily. It's pretty much essential to any d

Good applications tend to get the database right first - since you can always re-write the mid-tier code relatively easily. It's pretty much essential to any developer. Further it's a ridiculous superpower if you're not a developer - it's so empowering for anyone on the business side with questions to just go look in the db.

dudul 7y ago
I actually fully disagree. I find it much easier to "fake" the DB in the first stages (like just store shit in memory) where you explore and understand what your system must do, the questions it should answer with data from the DB, etc. Then, just replace your fake repo with an actual DB and you're done. And it goes with what you're saying: changing a schema is not as easy as changing the code. So start by really understanding what you need to do, and then build the schema at the end.
- scarface74 7y ago
  I agree and especially with C#, your LINQ expressions will be the same whether you are working with in memory lists, Entity Framework for RDMS’s or Mongo for Nosql. Your queries will be translated appropriately either way.
exdsq 7y ago
Weird, this is completely opposite to what a lot of people I've worked with have said. What do you think about having business logic in the DB layer too? I saw someone on another post recommending that which, again to the people I have worked with, is an antipattern.
- vbezhenar 7y ago
  Somewhat related quote: Linus Torvalds: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." IMO proper database design is extremely important. Code is fluid. You can replace it. Data is not that fluid, it's much harder to change it. Database should contain checks to ensure that bad data won't be saved. I don't think that complete business logic should be in database. Keep data in database, keep your code in your application. Database is responsible for data storage and some data validation to prevent misbehaved apps storing obviously bad data. Application is responsible for everything else.

dudul 7y ago

I actually fully disagree. I find it much easier to "fake" the DB in the first stages (like just store shit in memory) where you explore and understand what your system must do, the questions it should answer with data from the DB, etc. Then, just replace your fake repo with an actual DB and you're done. And it goes with what you're saying: changing a schema is not as easy as changing the code. So start by really understanding what you need to do, and then build the schema at the end.

scarface74 7y ago
I agree and especially with C#, your LINQ expressions will be the same whether you are working with in memory lists, Entity Framework for RDMS’s or Mongo for Nosql. Your queries will be translated appropriately either way.

exdsq 7y ago

Weird, this is completely opposite to what a lot of people I've worked with have said. What do you think about having business logic in the DB layer too? I saw someone on another post recommending that which, again to the people I have worked with, is an antipattern.

vbezhenar 7y ago
Somewhat related quote: Linus Torvalds: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." IMO proper database design is extremely important. Code is fluid. You can replace it. Data is not that fluid, it's much harder to change it. Database should contain checks to ensure that bad data won't be saved. I don't think that complete business logic should be in database. Keep data in database, keep your code in your application. Database is responsible for data storage and some data validation to prevent misbehaved apps storing obviously bad data. Application is responsible for everything else.