4 ms·

Another issue I have with ORMs is different projects end up with different views of the same database. Why don't you use a foreign key to that table? We don't

Another issue I have with ORMs is different projects end up with different views of the same database. Why don't you use a foreign key to that table? We don't have that table... Yes we do, it's not because you haven't defined it in your project that it doesn't exist! And... every project ends up with their own version of the "versioned schema", so to rebuild the DB, you need to aggregate all the liquidbase/flyway files from all the projects and run them all. When I wear my sysadmin/pseudo DBA hat, ORMs are one of my more prominent pain.

habitue 12y ago
I think this pain comes from using swl databases for integration, which is an antipattern in my book, and prevalent in the enterprise. Databases should have a single application talking to them, and have a service in from of them that makes it possible to get the data needed out. Services are easier to maintain backwards compatibility with, whereas databases are a massive pain to version and migrate and having to synch multiple teams to do such a job is a nightmare. That being said, I realize its often much more convenient at the beginning to have one database for integration. SQL is much more expressive than your service's interface will be, and in the beginning this seems like a killer.
- sanderjd 12y ago
  I've yet to see the real payoff of a database service like you describe over simply having a central database library. Perhaps the payoff comes if you want to use multiple languages, but if you don't, then pulling all the schema versioning and db-related client code into a single library that is used anywhere it's needed solves all the problems your parent brought up.
  - dorfsmay 12y ago
    I haven't seen any large enough entity using a single programing language across teams in a long time!
    - sanderjd 12y ago
      Fair point!
- acveilleux 12y ago
  So much this. Having had to be involved in the transfer of a DB that was used for integration from a legacy SQL DB to postgres, it was a pita (and not even my job) to deal with all the small and not so small things that broke. Especially things like monthly emailed reports and all sort of quick hack/tools that no one even remembers writing.
- dorfsmay 12y ago
  Good point. I don't think it is that difficult to setup at the begining, especially with the low cost of entry of REST, but forseeing what will be separate and distinguishable services early on is very hard.

habitue 12y ago

I think this pain comes from using swl databases for integration, which is an antipattern in my book, and prevalent in the enterprise. Databases should have a single application talking to them, and have a service in from of them that makes it possible to get the data needed out. Services are easier to maintain backwards compatibility with, whereas databases are a massive pain to version and migrate and having to synch multiple teams to do such a job is a nightmare. That being said, I realize its often much more convenient at the beginning to have one database for integration. SQL is much more expressive than your service's interface will be, and in the beginning this seems like a killer.

sanderjd 12y ago
I've yet to see the real payoff of a database service like you describe over simply having a central database library. Perhaps the payoff comes if you want to use multiple languages, but if you don't, then pulling all the schema versioning and db-related client code into a single library that is used anywhere it's needed solves all the problems your parent brought up.
- dorfsmay 12y ago
  I haven't seen any large enough entity using a single programing language across teams in a long time!
  - sanderjd 12y ago
    Fair point!
acveilleux 12y ago
So much this. Having had to be involved in the transfer of a DB that was used for integration from a legacy SQL DB to postgres, it was a pita (and not even my job) to deal with all the small and not so small things that broke. Especially things like monthly emailed reports and all sort of quick hack/tools that no one even remembers writing.
dorfsmay 12y ago
Good point. I don't think it is that difficult to setup at the begining, especially with the low cost of entry of REST, but forseeing what will be separate and distinguishable services early on is very hard.