This one time, at band camp, [EMAIL PROTECTED] said:
>Thank you for your response. You have a better perspective maybe you could
>give me some insite. I will tell you my situation. I'm starting work
>redesigning a large brokerage software applications. From PL/SQL to Java. The
>database is made up of several hundred tables that span over a few schemas. None of
>the operations that I'm performing on the database are really critical. e.g. No
>trades will take place though our software. All of that work is done on a trading
>database on a mainframe system. We're basically dealing with customer account
>lookups. Trade histories. Account open and close and some data feeds to a customer
>internet portal via some queues.
>
>Here is the problem. The schema is used by 20 or 30 different applications and to
>make even a minor change in the table layouts or structures requires a huge effort in
>changing the apps that access the database. Most of these apps are writting in
>Powerbuilder or PL/SQL and not all that interested in good object design. The
>database is a big mess (like most corporate databases) and I'm
>not going to be able to change it. I have to adapt to it.
>
>Even the most basic operations like filling a listbox require multi table joins.
>(three to fill a broker dropdown) Moderatly complex operations like opening a new
>account require that I touch 12-15 tables. The model of object to table relationship
>that Castor seems to be based on doesn't seem to fit well.
>
>Do you or anyone else on the list have experience with OR mapping Castor in
>particular being applied to one of these large muddled corporate databases? I'd like
>to find a fit but I'm just not seeing it right now. I may be stuck using something
>similar to EJB BMP.
Oftentimes, this type of challenge is addressed through the use of
views on the tables (and even views of views). The views are handled
by the database and they pose little to no additional overhead. IMHO,
views are available in most databases to abstract the complexity of
the actual tables for situations just like yours. Views provide a more
logical appearance and/or combination of the actual tables providing
easier access to the data.
BMP is a nice solution, but it's a very big headache to maintain. Think
about it - tons of EJBs containing tons of custom SQL that may or may
not change on a regular basis. It's certainly doable and it's very
common. However, the maintenance of at least some of these sitations
can be lessened through the use of O-R mapping.
BTW, object-relational mapping in general is founded upon the principle
that an object model can be mapped to a relational model. By no means
is this idea restricted to Castor.
Bruce
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
