Some observations on databases in general, implications when using COBOL, and a portal that provides data on SQL and Normalization

(c) Peter E. C. Dashwood - 2017

Migrating ISAM to RDB...

PRIMA has a wealth of experience at doing this and we have developed tools that fully automate it. (For more on the DB migration Tool, click here...) However, there will be people who want to do it manually, so the following is provided to help you avoid some of the common pitfalls...

There is a link to "The Path to Relational Database" on the Portal page.

The future...

The Relational model has served us very well and will continue to do so for some time yet. SQL is an easy skill to acquire but in some circles it is already looked on as "obsolete". "NoSQL" databases have become available and there are also "graph" databases which use a completely different syntax for management (SPARQL is a popular one). These DBs are really excellent in certain spheres, like resource management (RDF), but maybe not so much for general use.

Microsoft produced their "Language Integrated Query" (LINQ) which has a different, arguably better, syntax from SQL (although there are similarities) and this seeks to be nothing to do with Relational DBs, but rather a "general purpose data manipulation" language. You can run LINQ against a table in memory, a collection of items in memory or on a file, or against a Database (which doesn't HAVE to be Relational...). In fact, any object in .Net that implements an IQueryable interface. PRIMA has standardized on LINQ for our internal use and we no longer use SQL. The LINQ engine has capabilities that are way ahead of most DBMS and it pushes the DBMS to get better performance. We ran tests of Fujitsu NetCOBOL programs using SQL through ODBC in the way described in Fujitsu docs, then converted the access to LINQ. LINQ was up to 5 TIMES FASTER!

NOTE: LINQ is NOT innately available with COBOL; if you want to use it with COBOL, you MUST implement a DAL architecture. (Our tools do this automatically.)

Summarising...

Whether you are starting from scratch and designing and building your RDB, or you are trying to get an RDB that will accurately and efficiently reflect the data enclosed in your existing indexed files, there is a great deal to be considered and implemented. Do not underestimate the work involved and beware of people who say: "All ya gotta do...". Here are some RECOMMENDATIONS:

1. Use the PRIMA tools; they come with support from us... (Yes, I would say that... but you really should consider it. Contact us.)

2. If you are new to RDB technology, get someone who knows about it on site for a while to guide and advise. This is particularly important during the "design" phase of your RDB because a bad design, or something that perpetuates the inefficiencies in the existing system, will cost you more than having a consultant for a while. (If you use the PRIMA Migration Toolset, you will get an RDB design that is generally as good as an experienced DBA would produce for you.)

3. If you are using COBOL and are more likely to be doing "record processing" than collecting ad hoc fields, definitely use the DAL approach. DAL is good no matter what language you use, but it is particularly good for use with COBOL.


(For information about the "nitty gritty" of SQL, DDL, Normalization and other DB related matters, visit the Portal)

prevPge  

Settings