Tweet
DDS is self documenting, and the CHGPF command is great after a change is made to DDS for implementing change to the PF. Less complexity, better documentation, and easier to use. Some specific requirements may support SQL better.
-
-
iSeries DB2 Training
Al, Since you asked about training, My company does offer training on SQL and DB2 and other topics. Feel free to write me at kevin.forsythe@dmcconsulting.com for more information. as to benefits... I believe that SQL is much more flexible than DDS. It is used thoughout the industry, providing a wider range of uses than DDS. DDS requires you to maintain a separate source object that you must keep track of and maintain to ensure the integrity of your database. An SQL database is self defining. No additional objects required. No source code to loose. The ALTER TABLE command is just as easy to use as the CHGPF command, but doesn't need a DDS Source member. A database created with DDS is not self defining, it is defined by a DDS source member and requires the use of that source code to manipulate the database. The commenting ability of SQL is just as good at documenting a database as the Text keyword in DDS. Generally we are all more comfortable working with familiar tools and familiar languages. SQL may be new to many of us iSeries veterans, but it is the direction of the future. Its time we all got comfortable with that. Take care, Kevin -
iSeries DB2 Training
Kevin, With a DDS created file, the file will tell you what source it came from. The SQL created file will not tell you where it came from. And using proper change management (which Sarbanes Oxley mandates) will solve the source tracking problems. (Of course, using proper CMS will solve the problem of not knowing where the SQL statement that creates is, as well.) Also, unless I'm mistaken, a DDS logical file can do more than any single object from SQL, in other words, it can do much of what an SQL view can do and much of what an SQL index can do combined. Of course SQL is much more versitle in the depth of those single objects. Having said all that, SQL has ALWAYS been the native interface to the DB2 database. This is not a NEW direction by IBM, but indeed, the only one. DDS is just another interface into the SQL/DB2 engine. It's indexes are created by the same mechanism that creates an SQL view/index. I agree totally with everything else you said as to the advantages of SQL over DDS. Moving to SQL for creating and managing files sounds like a good thing (regardless of what it may have sounded like I was saying above). It takes another set of skills and a different approach to change management, but these are small shifts in paradigms. -danComment
-
iSeries DB2 Training
Dan said: "which Sarbanes Oxley mandates" Whew! Those two words make me shudder. Everyday I thank the stars that I work for a private company and don't have to worry about such matters! chuck Opinions expressed are not necessarily those of my employer.Comment
-
iSeries DB2 Training
Chuck, I don't usually post a message just to say "No Kidding", but... No kidding. -danComment
-
iSeries DB2 Training
kforsythe said: A database created with DDS is not self defining, it is defined by a DDS source member and requires the use of that source code to manipulate the database. I have a problem with this statement. I can manipulate a file created by DDS using SQL, RPG, View, even DFU. I can delete the source from the system and still manipulate the database. Maybe I'm not understanding what you mean by manipulating the database. To me it is changing, adding, deleting data to the database. If you mean to manipulate the database DEFINITION then I can agree with you. But in the past (haven't done it on more recent systems) depending on the amount of data in the file if you tried to use the alter table command to let's say enlarge a field it could take a very long time. There have been and I still believe some performance issues with SQL and large databases (in comparison with "traditional" HLL Language accessing). Do not give up the tradition DDS. So far after 20+ years on S/38, S/36, AS/400, iSeries, mainframes, etc. I have yet to have heard a convincing argument to go strickly SQL definitions. Especially since SQL can be used against a physical/logical file created by DDS (I think you can even create a view using sql over a file created by dds, since the architecture is all the same). just my opinion, no matter how scatter brained they may sound.Comment
-
iSeries DB2 Training
I've been following the posts for a little while now and thought I'd add my own $.02. Virtually every other RDBMS forces you to use SQL in every program that accesses the RDBMS. TTBOMK DB2/UDB/400 is the only RDBMS that allows access with direct reads and writes. IMO this is not only special but also advantageous. I believe that given the choice developers in other avenues would actually prefer the ease of direct access without SQL use, and simply by using name. But then again the concept of a "Virtual Store" is not available anywhere else but on the AS/400. (Neither is a separate I/O processor, but that's a slightly different topic). Don't read into this statement things I haven't said. I am not "dissing" SQL, or saying that SQL should never be used. DaveComment
-
iSeries DB2 Training
Our shop is seeking in-house training for DB2 and Sql. Our focus is to move away from DDS and utilize the sql functions to create pf / lf / indexes and place the business rules within DB2. I would appreciate any input as to who or what company that you would recommend for this training. thxs alComment
-
iSeries DB2 Training
Glen - you are right in that I was talking about manipulating the design of the database, and you are also correct that sometimes that is a slow process if the database is large. That is true whether you use SQL or DDS to define it. David, is right on the money when he tells us how great it is to have the option to use either SQL or the Native I/O. We should always use the best tool for the job, whether its RPG, CL, SQL, or DDS. It's great that IBM gives us a system that supports all thse options and at the same time is one of the most stable and cost effective systems in the world. But before we all enthusiasticly embrace the "code and let code" credo... Lets also remember that IBM has made it clear they are not making any significant investments in DDS capabilities. Most, though probably not all, new features of the database will be implemented through SQL with no DDS counterpart. Can DDS define a Row ID column? Can an RPG program operate against a Binary Large Object? Does it makes sense for IBM to continue to spend the money to maintain two different database management and access methods? IT seems to me that they are standardizing their hardware, their DB, and anything else they can, across all platforms. The day may come when our beloved DDS will no longer be a viable option. For now - you can do either as you see fit. But do you think DDS is still going to be a good option for the next 20 years or even 10? Take care, KevinComment
-
iSeries DB2 Training
> Glen - you are right in that I was talking about > manipulating the design of the database, When I need to use SQL to manipulate the design of a database (i.e CREATE TABLE, ALTER TABLE, COMMENT ON, CREATE PROCEDURE...) I put the statements in a script. On OS400, that would be a source member and RUNSQLSTM to execute them. The point being that one can save/reuse SQL DDL just as easily as one can with DDS. A disadvantage to DDS is that there are database attributes that live outside of it like triggers, RI and stored procedures. That is to say that one doesn't define any of these things in the actual DDS member, but outside of the DDS in CL commands. Except for stored procedures, for which there is no command - and this trend will continue. I'm not putting down DDS; just pointing out a spot where it doesn't sparkle as much as it used to. --buckComment
Comment