It's not a simple thing to explain, but the gist of the method was:
(1) Figure out what data you really want to be storing for the drawings (and other documents) themselves. Stuff like title, author, date, etc. Try to make as many things as possible auto-filled out when someone enters a record (i.e. use the date on the system and the username as default values)
(2) Look at revisions for documents, and set up what kind of data you want for those, too. How can you automatically update revisions (i.e. -, A, B, C, ...) when a change to a document is made.
(3) Pick a database program to serve as the back end. I like MySQL because it's the most solid piece of software I've used.
(4) Map out what kind of tables and columns you're going to use to represent the data you specified in steps 1 and 2.
(5) Pick your language. I used Java, mostly because there are a lot of nice libraries of functions available and it's portable, etc.
(6) Get the interface module (API) for the database server you are running, so you will be able to access your database programmatically.
(7) Write tons and tons of code to handle the database manipulations, user interface, and all the other functions you need. The hardest part of this and most programs is making the interface easy to use but powerful enough to do somewhat sophisticated operations. And, despite all your best efforts, a user will inevitably do a bad thing that you will say "but, WHY would you ever do that?".
(8) As with any such complex undertaking, I learned that it's best to take the time on the front end to really get the database tables as small and efficient as possible, and put as much error checking (and prevention) as possible. Comes from past programming efforts where my co-worker who tested my stuff was a hilarious purposely mischievous user. It was a game for me to thwart his efforts to break things. Fun stuff.
