|
----- Original Message ----- From: "Al Barsa" <barsa@barsaconsulting.com> To: "Midrange Systems Technical Discussion" <midrange-l@midrange.com> Sent: Tuesday, January 07, 2003 5:27 PM Subject: Re: Changing database to SQL from DDS > Skip Marchessani does a talk at COMMON on the differences in defining a > database in SQL versus DDS, and I would say that all-in-all DDS does a > better job. SQL is trendy. One of the reasons that System/38 databases > were so solid was the existence of the DDS REF keyword, so that you could > create a field reference file, and make all of the fields refer to each > other. au contraire, mon ami.... SQL is FAR from "trendy". It is the linqua franca of database. Period. You work with other databases, you work with SQL. As I, and others, have mentioned in many other posts, the reference functionality is available in the tools that you use to design, modify and create databases. Applied, it can be more consistent than DDS's REF keywords. Solidity of the database comes from the architecture of the 38 and 400, not the definition language. I have seen both DDS and SQL abused. > Much to IBM fault, in recent releases, they have enhanced SQL databases, > but not DDS. A prime example of this is EVIs (encoded vector indexes). Fault? They said they would do it. They did it. Foreign key constraints... the very thing that makes the database reverse engineering operations possible, are not possible in DDS itself. You must use commands or SQL. And, again, the tools shine here. Tie two files together and the foreign key constraints are applied. Period. > Regardless, unless you are doing something that can only be achieved in > SQL, the final databases you get are comparable. Comparable is an understatement. Outside of a few flag bits that indicate the creation "source", and functionality that appears only in SQL, the implementations are virtually identical. As for your original question, converting "to" SQL is more of an implementation at the code level with embedded SQL statements for access (DAL, Data Access Language) replacing native I/O and sorts (FMTDTA) or OPNQRYF commands. You can choose to design and build in SQL DDL (Data Definition Language) independantly of embedding it in programs. It's just that without invoking the optimizer through DAL, you won't gain performance advantages produced by creating the "perfect" (as Bob D calls it) index over the files. And likewise, the programs that use logical files and native I/O would continue to be dependant upon the existance of those logical files, thus hampering index tuning operations. Tuning thus remains a programming chore and not an independantly created index chore. =========================================================== R. Bruce Hoffman, Jr. -- IBM Certified Specialist - iSeries Administrator -- IBM Certified Specialist - RPG IV Developer "If you pick up a starving dog and make him prosperous, he will not bite you. This is the principal difference between a dog and a man." - Mark Twain
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.