7 ms·

Could maybe somebody of the older experienced people comment whether this is a good idea? I find it intriguing, but maybe I am just one generation behind and y

by weitzj 11y ago

Could maybe somebody of the older experienced people comment whether this is a good idea? I find it intriguing, but maybe I am just one generation behind and you were to say: "Been there done that. This strong dependency on the database was really not a good idea in the long run because... "

rodgerd 11y ago
In my experience (and I'm older these days...) databases are a much rarer migration than programming languages. I deal with stuff that's still in (heaven help us) VSAM files, accessed a mix of assembler, COBOL, C, Java, TCL, C#, C++, Pascal, and so on and so forth.
- bdcravens 11y ago
  I work on a system has has iterated through 3 distinct languages while relying on the same database.
  - spacemanmatt 11y ago
    Integrating at the database is a powerful pattern. I see some value for larger organizations to go a step further and integrate at a higher service layer, because one database could never support the entire enterprise. But for orgs that fit in one database, it's great, IMO.
- spopejoy 11y ago
  Agree, the received wisdom has always been database vendor choice as a ten-year commitment, as opposed to almost anything else. It's a reason to avoid databases :)
  - spacemanmatt 11y ago
    Strongly disagreed that it's a good reason to avoid databases. If you are going to collect data of any value over a long period of time, pick a horse and stay on it. Over time, technology and business needs might force a re-evaluation of that position, but you don't want to build around unmeasured plans to maybe switch databases at random some day.
    - spopejoy 11y ago
      It was a joke, implying that people who can't commit will avoid databases like the plague
pjc50 11y ago
I like the way you think. In the old days, DB vendor independence was considered important, because the Free databases were not considered good enough for Enterprise use. It had to be Oracle or IBM. Even if you were starting out on MySQL, you wanted to retain portability for when you moved to Oracle. Hence building ORMs as an abstraction layer allowing vendor independence and more Enterprise-y Java. There's also the "demarcation" issue. Traditionally databases were administered by change-averse DBAs who didn't want you stealing their CPU cycles to run your stored procedures, and were generally extremely averse to change.
- benkant 11y ago
  > There's also the "demarcation" issue. This is probably just as significant as vendor independence or technical issues. But I remember it a little differently. In the old days you'd have programmers who did the code and the DBAs who were tasked with making sure the data wasn't broken. They would write SPs, use constraints and triggers etc. Depending on the team programmers might do these as well or instead, but it was the DBAs domain ultimately. Then programmers wrote ORMs and started doing all that stuff in code and somehow managed to seize control of data validation and semantics from the DBAs.

by weitzj 11y ago

rodgerd 11y ago

In my experience (and I'm older these days...) databases are a much rarer migration than programming languages. I deal with stuff that's still in (heaven help us) VSAM files, accessed a mix of assembler, COBOL, C, Java, TCL, C#, C++, Pascal, and so on and so forth.

bdcravens 11y ago
I work on a system has has iterated through 3 distinct languages while relying on the same database.
- spacemanmatt 11y ago
  Integrating at the database is a powerful pattern. I see some value for larger organizations to go a step further and integrate at a higher service layer, because one database could never support the entire enterprise. But for orgs that fit in one database, it's great, IMO.
spopejoy 11y ago
Agree, the received wisdom has always been database vendor choice as a ten-year commitment, as opposed to almost anything else. It's a reason to avoid databases :)
- spacemanmatt 11y ago
  Strongly disagreed that it's a good reason to avoid databases. If you are going to collect data of any value over a long period of time, pick a horse and stay on it. Over time, technology and business needs might force a re-evaluation of that position, but you don't want to build around unmeasured plans to maybe switch databases at random some day.
  - spopejoy 11y ago
    It was a joke, implying that people who can't commit will avoid databases like the plague

pjc50 11y ago

I like the way you think. In the old days, DB vendor independence was considered important, because the Free databases were not considered good enough for Enterprise use. It had to be Oracle or IBM. Even if you were starting out on MySQL, you wanted to retain portability for when you moved to Oracle. Hence building ORMs as an abstraction layer allowing vendor independence and more Enterprise-y Java. There's also the "demarcation" issue. Traditionally databases were administered by change-averse DBAs who didn't want you stealing their CPU cycles to run your stored procedures, and were generally extremely averse to change.

benkant 11y ago
> There's also the "demarcation" issue. This is probably just as significant as vendor independence or technical issues. But I remember it a little differently. In the old days you'd have programmers who did the code and the DBAs who were tasked with making sure the data wasn't broken. They would write SPs, use constraints and triggers etc. Depending on the team programmers might do these as well or instead, but it was the DBAs domain ultimately. Then programmers wrote ORMs and started doing all that stuff in code and somehow managed to seize control of data validation and semantics from the DBAs.