This is a discussion on Re: How I learned to stop worrying and love the RDBMS - Hewlett Packard ; Denys writes: >With the continually dropping prices on hardware and the >attendant increase in hardware performance, selecting an >RDBMS as a migration target from IMAGE is the only sensible choice. > >The capabilities afforded by a proper RDBMS are astounding ...
>With the continually dropping prices on hardware and the
>attendant increase in hardware performance, selecting an
>RDBMS as a migration target from IMAGE is the only sensible choice.
>The capabilities afforded by a proper RDBMS are astounding
>and are growing every year as the hardware continues to
>increase in price/performance; the growth in capabilities is
>For IMAGE aficionados, the preceding statement will most
>probably be seen as heresy, but as customers demand more
>information out of their ever growing data repository, the
>RDBMS has moved far beyond IMAGE.
Well said and I would agree 110%
At QSS we developed an api, we call QDBI, which is used to abstract
SQL databases so our cobol applications can connect up to any number
of databases without concern for the particular flavor of rdbms.
Gives us a quick 'drop-it-in' solution which mirrors the TI calling
structure, but provides for simple extensions/tuning to take advantage
of the SQL rdbms capabilities. Port it. Run it. If too slow then tune it
otherwise leave it alone.
Sure, if you were doing all this 10-years ago you would be hard pressed to
get enough cpu to migrate your TI apps to sql/rdbms. But today, hardware
is so dang fast it pretty much mitigates much of the concern.
Of course, you can still do 'brain-dead' things that consume lots of cpu
and take forever, but like all things you learn and create new solutions that
leverage the sql/rdbms power to solve those problems.
For its day TI was a great tool. That day has passed. Just like I don't use
RMS (DEC) anymore there will come a day I don't use TI. No sadness, just fond
memories for the fun we had with TI in running circles around vax solutions
that used bloated db solutions.
BTW, we have done a bunch of PostgreSQL and find it to be a wonderful database, but
our customers are choosing MS SQL Server at a rate of about 80/20 over PostgreSQL,
with Oracle being almost non-existent. But that is more due to our customerbase
than the technology itself.
We use dbvisualizer as a generic tool for sql/rdbms database access. Highly
recommended (java) tool.
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *