|
>Take a representative number of your files (master files, >transactions, history, etc.), stick them in the DB on the >$2000 PC and have then run a hundred simultaneous queries >and updates against large numbers of records. >Then do the same on the $100,000 system. I think you'll >find that the $100,000 system copes a lot better with the >load -- but you knew that didn't you? Yes sir! Again, I managed to misstate my main idea. I should go take a class in writing! My point is that thousands of recent university graduates are indoctrinated that JDBC is THE way to interact with a database. That's apparently in the syllabus. What's not in the syllabus, and therefore learnt by implication, is the idea that cheap PC's do this work Very Well. They seem to pick up that idea mainly because they've worked against small databases. I remember the look on one fellow's face when I explained that a typical telephone call record transaction file contains some 20 million records per month. The biggest table he'd seen to date was some 5000 records. It's this unspoken understanding that JDBC works quickly and efficiently with cheap hardware that's shooting us down. When you mention large databases to them, they answer with a flip "add more servers." I'm not going to travel too far down this road in this list; pretty much all of the posters here are already using the 400 and don't need to hear the same story again. >Although I'm a firm believer in the idea that the >data should be managed at the database and that >means few or no raw queries in client code, >just SQL CALLs to stored procedures. I don't >care if the stored procedures are SQL, >embedded SQL, or native I/O. Certain stored >procedures may not be portable but then you chose >your database for many reasons and portability >should be pretty low on the list. Indeed. Our DB is on the 400 because it was the best machine for the job "way back when." Now we have lots of RPG code that talks to that DB, but the DB isn't completely normalised, nor is it really ready for triggers and RI rules. None of the existing RPG code knows how to handle disk I/O errors (RI violations.) The "portability" issue is the Java mantra. All I care about is that the Java people seem united in their desire to use JDBC to reach the database. Regarding raw SQL vs. stored procedures, we have a (probably typical) situation where most or all of the database integrity is enforced by application code. We're very slowly migrating some of that "pseudo RI" into stored procedures to be used by the RPG and by stored procedures (write once, reuse many times). We're just not there yet. It's an ongoing process. Market forces being what they are, our client code MUST contain raw SQL just to deploy it quickly enough. Nobody thinks this is a good thing, but there isn't a whole lot we can do about it. --buck
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.