How Does a Database Replace CAD Files?

Anyone who used CAD in the period from 1995 up to about 2010 was very lucky. You got to see an explosion of new tools to create and control CAD models. The CAD model went from just a geometrical representation to a tool to simulate every aspect of the manufactured part’s use as part of a product.

Since 2010 there have been some modeling developments, but they have been in synchronous and subd tools, and not as widespread as the previous changes.

Most of the engineering design technology industry has focused on one two things: cloud delivery of applications, and 3D printing. Those can be exciting in their own way, but one is really an IT delivery development and the other is a 30 year old technology that we finally figured out how to commercialize. So, its exciting, but not that exciting.

If you’re an old timer, you might remember referring to CAD files as “databases”. CAD files today and even from decades ago were much bigger than most other files used in business applications, but the word “database” was not used in the same sense in which we use it today. In the past, I think the word database was used just to connote any large file with a lot of data in it in some organized structure.

I’m not here to write about database structures/schema, but I would like to shine a little light on how a CAD system can use a database instead of individual files for parts, assemblies, and drawings. To do this, and I know this isn’t a 100% applicable analogy, but I’m going to use this blog as an example.

Just as a disclaimer, there are relational and non-relational databases, and while CAD systems like Onshape are based on a non-relational database and this blog uses a relational SQL database, the distinction between files and databases is bigger than the distinction between relational and non-relational databases, so I’m treating the types of databases as if that difference doesn’t matter, even though it actually does matter, but only to people who know the difference. All that just to say please don’t accuse me of conflating the two types of databases, I’m just simplifying for this example.

HTML (hyper text markup language) is the simplest way you can create a website – data read by a web browser. The html code contains a lot of text, CSS formatting, and it formats the display of that text and calls various other types of files for more complex information, like images. So the text is included, and the images are referenced. This is kind of like a CAD drawing, where the actual part on the drawing is an external reference, but the section lines, notes, drawing border, and other things are kept inside the drawing file.

But there is another way of setting up web sites. You can have templates that show what kind of data goes where, and then the actual data to fill in the pages comes from a database. There are many kinds of data. Posts, titles, images, text, status, date, author, etc. And then all of that data is pieced back together into a set of pages that are displayed in a web browser.

CAD data is larger and more complex than a blog post to be sure, but you can see how different types of data within the CAD document types could be organized to create a part with infinite undo, for example, or a part that could be shown in different configurations or revisions easily. And in a world where big data kept in big databases is king, it makes sense that our complex CAD models can take advantage of some of the developments in big databases. How we store the information is another IT development, but it does simplify a lot of the work, like the file management side of things.

I’m not sure about the proprietary details of how databases for something like Onshape is structured, there are a lot of ways to do it. Since it is a history-based modeler and have infinite undo, they could just store each command as a field in the database. Or they could store individual features. The very cool FeatureScript functionality with custom features might give away some of how the CAD model is broken down and stored as smaller parts in the database.

And because databases are set up to be accessed simultaneously by many users, there are a lot of obvious benefits of using databases for CAD files. Including that PDM function is taken care of for you. Search, share, meta data, reports, etc. All of this is much easier with a database. In fact, most PDM tools use a database to control the metadata and file locations associated with traditional file-based systems.

Unfortunately right now the only way to use database CAD is to get it on the cloud, unless you’re a very big organization. There are companies who can pay enough to be allowed to install what we normally think of as cloud software on their own, internal, private cloud. I can imagine 3 reasons for this. Security, control and security.

If we could get the database CAD to work on a local network for small and medium organizations, I think the CAD industry might be something to fall in love with again. But the appetite for growth whether it’s good for people or not is just too strong. Corporations everywhere have totally lost sight of the humans from which their success is built.

The bigger the pot of gold we create with an online repository of product development data, the crooks and criminal states won’t be able to ignore it. They will get in. Identity theft, physical breaking and entering, hijacking a connection, one way or another, big targets are not immune from hacking, regardless of what the sales and marketing say.

What started as a CAD industry has developed into PLM, and now engineering technology. It developed as a series of small companies developing a single product or just a few software products. It has evolved into several large players who control the technology to work for the large corporation rather than the small independent makers or developers or inventors – humans.

With all human endeavors, things grow. Cities grow. Companies grow. The difference is that human beings know when to stop growing. If we kept growing physically, we would eventually die under our own weight, but we have evolved the sense to stop at a reasonable level. Not so with human endeavors, however. Population, cities, organizations grow until they get too big to support themselves, then they die. This is why I think we’ve already seen the best of what the CAD industry had to offer. It has grown to the point where it’s hard to recognize human traits. For a while it was focused on serving the needs of smaller users, but now you have to be much bigger to get attention. This is kind of a side story, but I think it is elemental to the overall picture. When organizations grow past the human scale, they are no longer relatable. Technology needs to be human scaled to be most effective.