When designing your data base, did you use ERD's?

[Dave Fullerton]

Hi all:

I am taking some university courses (working toward a Bachelor of Commerce degree), and one of them is about databases.  A major topic of the course revolves around Entity Relationship Diagrams (ERD's).  When I mentioned to the professor that in over 35 years in the business,  I had never seen one, she was surprised.  So, I thought I would take a little survey.

This forum is used by companies that develop business software around the world.  When you were developing your application, did you use ERD's?

Any input would be appreciated.

Regards

Dave Fullerton

[keith.mcbride]

I have used them off and on in the past (1990s), but normally for documenting what as done vs during design. Visio at on point had some tools to pull in the schema from SQL Server and to assist in the design which made it much easier.

My issue was once you got over 10 or 15 tables it was too big and unwieldy to be useful unless you printed it out in multiple sheets and taped them on the wall.  Then it would be out of date the next day.
If you kept it up to date it could be useful in an environment with many programmers and useful as a way to document the tables you have. It just has to be someone's job to  keep it up.

A good homework assignment, should anyone decide to accept it,  would be a tool to read the PVX dictionary and have a side file to hold the relationships between tables. Then you could create an ERD from that. The auto layout is the hard part.

Keith

[Dave Fullerton]

Hi Kieth:

The cost associated with keeping it up to date would be prohibitive for a small company. and I would think most companies that monitor this forum fall into that category.  It is a form of documentation, and as such, it can become a black hole for resources (cash and manpower).  I agree with you, it is probably out of date as soon as it is created.

Regards

Dave

[Stéphane Devouard]

Hi Dave,

After being let go by Explorer Software at the end of 2018, I have followed a 5-months training last year followed by a 2,5 months internship. The goal was to gain skills in mainstream web development languages & frameworks (PHP, Symfony, Java, Android, Javascript/jQuery, IONIC/Angular/Typescript, MySQL, MongoDB) as well as modern software design (UML, Object Oriented multi-layered apps, Relational Database Design). I needed to find another job and since you can consider the french ProvideX market as slowly dying, it was time to move on.

Although my past experience with ProvideX allowed me to get in touch with SQL & RDBMS as well as the ProvideX implementation of the object paradigm, it was also the very first time in 30 years I was seeing Classes diagrams and E/R diagrams as well as the methods and techniques to build them.

In 1986-88 french software programming schools, you learned COBOL and GW-BASIC, using the built-in ISAM files for one, and building them yourself for the other. I also learned a bit of dBASE III+ during the second year. No SQL courses and no UML / OO design at the time.

When I joined my first employer in 1989, they were still using Tbred, I was the one who discovered ProvideX and advocated for the migration of the application. There were some attempts to migrate the ISAM files to SQL backends, but all were cancelled before being completed. The only documentation available when you started working on the software were the file layouts. Which could not be imported into the PVX Data Dictionary as the files were non-normalized and the DD did not support them back then (around 99-2000, before PVX V5).

When I joined Explorer in 2008, their SQL migration had been done for years. However I never saw any ERDs there, not even a Merise Physical Data Models.

In my experience, when you migrate ProvideX files to SQL, you only change for a different data store, and rarely enable all the power of the RDMBS engine -- I can be wrong, but I don't think after migration, people add foreign keys constraints to enforce referential integrity. Either your legacy BB application stores data forever without any archive/purge, or it does purge files but has referential integrity checks already programmed at the app level, when a user wants to remove some static data (a customer, a vendor) and the system needs to search all the transactional data (invoices, orders, etc...) to make sure the entity to delete does not exist anymore in your detail files.

BTW, I passed a final exam on January 8th. The official results are unknown yet (probably next week) but I got some not-official info from the main trainer who discussed with the examiners, and he told me not to worry about it ;-) I now have the equivalent of a BS degree in software design & development (I only had an associate degree from 1988). I am also in the process of creating a small one-person consulting & development services company to do free-lance work for the company where I did my internship (using ASP.Net MVC with C#). If you need any help with your db courses, feel free to pm me, I'll be happy to help an old fellow ProvideX programmer ;-)

[Dave Fullerton]

Hey Stephane:

It's nice to hear from you.  Congrats on your continuing education ;-).

I am pretty sure that Jim didn't use ERD's when he started Explorer Software.

When I took my first Computer Science - Data Processing course in the early 80's it was GW-Basic, RPG II, Assembler, and Cobol.  Flow charts were mandatory as was psuedo code for the cobol routines.  When I started at MAI, I asked about flow charts and psuedo code forms, and was practically laughed out of the office ;-).  A case of things important at the academic level that don't really translate to the business world.

Take care

Dave