6 ms·

I've been dev since I graduated. I had been everything else during my intern (dev, qa, test-automation developer, tools dev, build engineer, integration enginee

I've been dev since I graduated. I had been everything else during my intern (dev, qa, test-automation developer, tools dev, build engineer, integration engineer, etc). Are you saying that Rails schema migration can only solve 10% of your migration needs? That kinda suck bro.

viraptor 15y ago
Migration tools are great once you stop changing the schema very often like it happens when a project starts. This of course depends on the project... if you can have a full design from the start, it's probably going to work too. If you don't know the exact requirements or way to get there - not so much.
- hello_moto 15y ago
  If you change your schema once every 2-3 days, something wrong with whomever leading the software project. That's like writing a software with zero planning or lack of knowledge for the problem domain. I don't care if it is a startup or not. Come up with a very simple idea, draw the models in ER diagram, implement that stuff. It's very hard to imagine that tomorrow suddenly all relationships need to be changed. Even if that is the case, scrap your Repository/Entity model and start from the beginning. Nothing can help you much if the fundamentals are wrong.
  - mrkurt 15y ago
    Everything else in a software project changes frequently, especially during the early days. "Fundamentals" don't help you know more ahead of time and it's really nice to be able to quickly adjust when you come across something you hadn't anticipated. I tried building a small side project with Postgres about 8 months ago (after not really doing rdbms stuff for 18 months before) and was amazed at how inflexible it felt, and how much frustration used to seem normal.
    - lwat 15y ago
      Could you elaborate please? What were you doing and what made it feel frustrating and inflexible exactly?
    - einhverfr 15y ago
      That's what prototyping and peer review are for, I write up a schema, send to everyone else on the team, get feedback. If users are invovled get it from them too.... take in all the feedback, write up a new draft, wash, rinse, repeat until running out of shampoo (i.e. feedback)..... Once things are pretty stable, do a prototype, address any oversights, do the real thing. It's not rocket science.
  - Joakal 15y ago
    As a startup, change of minds is pretty normal to the point that it's far more better to have the tools to quickly implement it rather than plan/document it well. The only documentation is the general gist behind the database. If it prototypes well, then further refine it with ER diagrams for future maintenance. Why is planning everything without validation better than above?
    - hello_moto 15y ago
      small to medium changes? find a better migration tools. large changes? throw away and start over; tools like Rails can help you get up and running really quickly. I rarely see people go back and fix the mess.
      - hammerdr 15y ago
        To be frank, you're talking out of your ass. Maintenance takes up about 50% of all IT budget [1]. Most individual pieces of software will spend 2-6 times (considering the average life cycle of an in production software product to be 2-4 years) more money on being maintained than being developed. Data migration is a massive problem for any organization with data sets at any scale. RDBMS, in general, has gotten in the way of those migrations. People aren't looking at NoSQL just because they cannot sit still but instead are looking to find a better experience with handling data. I'm not sure if NoSQL is the right answer to that but let's give it a chance and see what happens when people are migrating MongoDB data in 3-4 years. [1] http://www.zdnet.com/blog/btl/technology-budgets-2010-maintenance-gobbles-up-software-spending-smbs-shun-cloud/30873 http://www.zdnet.com/blog/btl/technology-budgets-2010-mainte...
        einhverfr 15y ago
        Integration issues are best handled with good API's. Migration issues are a bigger issue but one thing that good use of RDBMS's give you is the ability to ensure your migrated data is meaningful. Not sure you can do that with KVM-type stores.
    - einhverfr 15y ago
- Devilboy 15y ago
  If you don't know the requirements to the point that you can't even design a data structure for your project... A schemaless database is NOT going to save you.
  - moe 15y ago
    Ever hear the term "exploratory programming"?
moe 15y ago
Are you saying that Rails schema migration can only solve 10% of your migration needs? Rails is a bad example here as their primitive migration-system still forces the developer to write those stupid migrations by hand. Django/South just auto-generates them which removes a huge chore from the daily development workflow.
- hello_moto 15y ago
  That's excellent! I think it's time for me to learn some Django.

viraptor 15y ago

Migration tools are great once you stop changing the schema very often like it happens when a project starts. This of course depends on the project... if you can have a full design from the start, it's probably going to work too. If you don't know the exact requirements or way to get there - not so much.

hello_moto 15y ago
If you change your schema once every 2-3 days, something wrong with whomever leading the software project. That's like writing a software with zero planning or lack of knowledge for the problem domain. I don't care if it is a startup or not. Come up with a very simple idea, draw the models in ER diagram, implement that stuff. It's very hard to imagine that tomorrow suddenly all relationships need to be changed. Even if that is the case, scrap your Repository/Entity model and start from the beginning. Nothing can help you much if the fundamentals are wrong.
- mrkurt 15y ago
  Everything else in a software project changes frequently, especially during the early days. "Fundamentals" don't help you know more ahead of time and it's really nice to be able to quickly adjust when you come across something you hadn't anticipated. I tried building a small side project with Postgres about 8 months ago (after not really doing rdbms stuff for 18 months before) and was amazed at how inflexible it felt, and how much frustration used to seem normal.
  - lwat 15y ago
    Could you elaborate please? What were you doing and what made it feel frustrating and inflexible exactly?
  - einhverfr 15y ago
    That's what prototyping and peer review are for, I write up a schema, send to everyone else on the team, get feedback. If users are invovled get it from them too.... take in all the feedback, write up a new draft, wash, rinse, repeat until running out of shampoo (i.e. feedback)..... Once things are pretty stable, do a prototype, address any oversights, do the real thing. It's not rocket science.
- Joakal 15y ago
  As a startup, change of minds is pretty normal to the point that it's far more better to have the tools to quickly implement it rather than plan/document it well. The only documentation is the general gist behind the database. If it prototypes well, then further refine it with ER diagrams for future maintenance. Why is planning everything without validation better than above?
  - hello_moto 15y ago
    small to medium changes? find a better migration tools. large changes? throw away and start over; tools like Rails can help you get up and running really quickly. I rarely see people go back and fix the mess.
    - hammerdr 15y ago
      To be frank, you're talking out of your ass. Maintenance takes up about 50% of all IT budget [1]. Most individual pieces of software will spend 2-6 times (considering the average life cycle of an in production software product to be 2-4 years) more money on being maintained than being developed. Data migration is a massive problem for any organization with data sets at any scale. RDBMS, in general, has gotten in the way of those migrations. People aren't looking at NoSQL just because they cannot sit still but instead are looking to find a better experience with handling data. I'm not sure if NoSQL is the right answer to that but let's give it a chance and see what happens when people are migrating MongoDB data in 3-4 years. [1] http://www.zdnet.com/blog/btl/technology-budgets-2010-maintenance-gobbles-up-software-spending-smbs-shun-cloud/30873 http://www.zdnet.com/blog/btl/technology-budgets-2010-mainte...
      - einhverfr 15y ago
        Integration issues are best handled with good API's. Migration issues are a bigger issue but one thing that good use of RDBMS's give you is the ability to ensure your migrated data is meaningful. Not sure you can do that with KVM-type stores.
  - einhverfr 15y ago
Devilboy 15y ago
If you don't know the requirements to the point that you can't even design a data structure for your project... A schemaless database is NOT going to save you.
- moe 15y ago
  Ever hear the term "exploratory programming"?

moe 15y ago

Are you saying that Rails schema migration can only solve 10% of your migration needs? Rails is a bad example here as their primitive migration-system still forces the developer to write those stupid migrations by hand. Django/South just auto-generates them which removes a huge chore from the daily development workflow.

hello_moto 15y ago
That's excellent! I think it's time for me to learn some Django.