While on my never ending quest to rid my self of the noob stank, I have often come across references to something called the drawing database. Every time I see this wording I'm left with a strange feeling. The closest thing I can equate it to is walking in on my parents having sex when I was 4. It was a strange mix of feelings. Absolute confusion mixed with a sense of primal clarity. Oh and sin... sprinkle in lots and lots of sin.

So after taking several baths to wash away the wickedness, I still had no clue as to what a drawing database is. I Googled my ass off and did not find much in the way of clarity. I busted out some old books and Googled some more and I finally think I have a semblance as to what it is. Now this could be completely made up, but I'm making an educated guess here. If I'm wrong and you get in trouble for repeating this garbage... that's what you get for listening to a noob.

<bullshit>

In short, a drawing database is another name for a DWG file.

Yup that's it. So... if this is all it is... why the hell bother repeating "drawing database." Just fucking say drawing file god damn it. I believe the reason they are called drawing databases is due to the origin of data structures in early computing. It helps to think about what a drawing file must do. If you remember from post where I talked about vector images there are basically a bunch of instructions in the file. If you think about all the options for these elements in a CAD file (color, size, style, type, etc.) there are lots of possibilities. This information needs some sort of hierarchical way to deal with it. You cant just say "line" and throw it in a file. Historically there were certain ways in which data had to be handled in computing. We take for granted the modern formation of a neatly packed file with all the data in it. Back in the day file size and computing power greatly reduced the ways in which we could store and retrieve information and so this lead to the file structures. I think the 'drawing database' handle stuck in the minds of the experts. It will probably atrophy away as the pioneers give way to the noobs.

</bullshit>

The interesting thing to me is the clarity that comes from thinking of the files this way. If you look at some of the commands and the methods used in handling DWG files it suddenly makes sense. For example consider the command PURGE. Intuitively one would think that if you are not using a particular element like a block or something in a drawing then the data for that element should also not be present in the drawing. But if you have ever purged a drawing you know you are getting ride of information that is present in the database but not in the visible drawing. The database structure also is a clue as to why raster images are not handled easily within AutoCAD (though Autodesk is always making inroads in to this). A database is not a file system but rather more like a meta data system and so files like raster images have to be crowbarred in. The consequences of the database file structure is huge when it comes to understanding and fully taking advantages of lisps and other user automated features.

If you are curious what kind of information is hanging out, you can use the LIST command or the DBLIST command to see. LIST will show the info for a selected element where DBLIST will dump all the data from the database or file. If you are curious I would use LIST, especially if there is a lot of stuff in a drawing. I created a drawing with a line and a circle and typed in:

 LIST

The window popped up with the information about the elements. In other words it popped up with the data that is in the database. If you try this and the window doesn't popup try hitting F2.



So in a nut shell all that "drawing database" means is your file and the information in it. When you start cracking things open it does help to think of the file as a database and may give you clues further down the road as to why certain functions are designed the way they are.