home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / object / 4611 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  2.1 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!think.com!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!seunet!kps!ded
  2. From: ded@kps.se (David Edwards /DP)
  3. Newsgroups: comp.object
  4. Subject: OO & transaction handling systems
  5. Summary: Are OO based systems practical for large databases?
  6. Message-ID: <1194@kps.se>
  7. Date: 21 Dec 92 12:53:02 GMT
  8. Organization: Kuwait Petroleum, Stockholm, Sweden
  9. Lines: 45
  10.  
  11.  
  12. Hello.
  13.  
  14. Being a neophyte to OO design & programing, I am wondering how 
  15. suitable OO based systems are for handling large amounts of data in 
  16. the form of transactions. The system we are dealing with today is data 
  17. collection and invoicing for large numbers of customers. (150.000 
  18. customers billing 1,000,000 transactions / month).
  19.  
  20. Currently we program in C & Oracle on a Pyramid MIS. The thing that 
  21. attracts me to an object way of doing things is that we have a large 
  22. number of types of transactions. There are also many types of 
  23. customers each of which have different functions associated with them. 
  24.  
  25. 'Sounds object-like, doesn't it?  But there are a lot of practical
  26. questions that are bothering me. Like:
  27.  
  28. 1) Am I breaking new ground here if I jump into OO? 
  29.    Does anybody have any experience out there with similar kinds of
  30.    systems that are OO?
  31.  
  32. 2) What advantages / disadvantages could one expect if one used C++ vs,
  33.    say, Smalltalk for this kind of system?
  34.  
  35. 3) Are there any products that can help with storage / access
  36.    considerations? 
  37.  
  38. 4) It is said that OO systems don't necessarily have performance problems.
  39.    Is that true for OO systems as they grow in size? The size and 
  40.    complexity were exactly why one chooses a relational DB. OO may help 
  41.    me with the complexity, but can handle the amount of data? Recall 
  42.    5 years ago relational DB were said to have performance problems in 
  43.    this regard.
  44.  
  45. 5) What (other) problems could I expect in implementation of OO for
  46.    this kind of system?
  47.  
  48. Thanks in advance,
  49.  
  50. David Edwards
  51. Kuwait Petroleum Svenska AB
  52. Stockholm Sweden
  53. ===============================================================================
  54. In theory, there is no difference between theory and practice.
  55. But, in practice, there is.
  56.