Printable View
I bought a book on transaction processing but it hasn't arrived in the mail yet. Are databases like Oracle, or ProgreSQL the way to go if you are building a transaction processing system for a business that does online sales. Does the database replace credit card oraganizations like CBill or IBill?
I don't understand why people are still paying programmers to write these things... there are several off-the-shelf brands that are excellent.
There may be privacy issues that a corporation requires, and therefore wants its own software built. In addition if no new development took place than I guess the days of computers are numbered.
ehh... I guess you have a point there... but new development will still occur... I just think there are some arenas where the ideas have been exhausted. The only changes that need to be made are OS dependent.
I bet most of the code for legacy systems has not been converted to more managable OOP. Most of the solutions to building a transaction processing system have probably been explored but I don't know too much about it. I don't know if it is a great idea always having to purchase upgrades from companies, I know of many large corporations that still do manual record keeping. Some of them don't want to pay vendors, however they don't mind paying their own employees to create an maintain a private system.
I can't speak for otehr companies, bu tI know that my company devs a lot of its software in house for the simple reason that it's in-house. The people that wrote the software are still there, so they can fix it if something goes wrong, plus, management has an easy scapegoat. They can also be assured that it'll work with whatever bugs they have in their system.
I think that will be the growing trend. The vendors are asking for too much. In my opinion, vendors who build and sell the OS should not do anything else.
>>I bet most of the code for legacy systems has not been converted to more managable OOP.<<
Organisations don't because it is too expensive to do so, plus not all legacy code needs to be rewritten. If you serves the purspose of the organisation, then they will develop some workaround to ensure that it does its job.
One reason why they might want to refactor some of the code in more manageable OOP is so that they can add functionality to their system. This is too difficult to do with action based code. Take for instance frameworks. This is a great idea for building a suit of systems that take advantage of reusable design rather than reusable code. True it is expensive as you say, but at some point they will not be able to work with the legacy system.
>>True it is expensive as you say, but at some point they will not be able to work with the legacy system.<<
Indeed this is quite true. You can only run a system for so long before it is not benefitting the organisation. There are many benefits to coding a system in OOP. However, the decision to change a system is often more to do with politics than performance - hence the case where the best technology or methods may not always be used.
That's definately true around here... although I'm the only developer in-house... and my priorities lie elsewhere. They'd love me to switch all the software to be SQL-server based instead of that damn ADO/Access based crap, but I have to work on my thesis. Plus having stuff built inhouse is useful if major changes are made.Quote:
Originally posted by Govtcheez
I can't speak for otehr companies, bu tI know that my company devs a lot of its software in house for the simple reason that it's in-house. The people that wrote the software are still there, so they can fix it if something goes wrong, plus, management has an easy scapegoat. They can also be assured that it'll work with whatever bugs they have in their system.
Has anyone here done this kind of work?
I've done in-house DB stuff (with Paradox), but never exactly what you're talking about - not many people buy power over the internet.
Hey Dean - let me know how that book turns out - I'd be interested in fooling around with that sort of thing.
Than you should also install Linux so that you can write standard C++ code with g++ and emacs, and use high quality free GUI emulation libraries, plus loads of other stuff covered under the GPL, in a pure multi user system.
I am also slowly looking into CORBA because it ties into transaction processing. There are a few main TP books. I still need to order the TP bible. It was written in 1993 but apparently it is still the best TP book around. That's because the solutions it uses are still applicable. When I started to look at .net I noticed that they were using solutions from the 1970's.