My only experience with a formal database in a design firm was on my first co-op with the Philadelphia Water Department. Though not technically a design firm (I worked in the plan review department), the principles are the same and I can easily see how they can be adapted to a design based application.
The database we used had all projects that had ever been reviewed by the department cataloged in it and ran on Microsoft Access. There were buttons that would open an Explorer window to the location of that folder on the network drive, as well as creating specific forms and exhibits for the final approval back to the client. Contact links were included in another portion of the screen, which listed the people the employees in the department were allowed to discuss the project with (typically just owner and engineer). There were input cells that listed the project address, site specific details, and other information that I've since forgotten by now (to be fair, it wasn't the most mentally stimulating work and I left that job 3 years ago).
This database was quite simple to use for day-to-day operations, as well as adding entries. The only tricky bit was making sure any folder created for a project was a direct copy of the generic folder. Any changes to the file structure inside this folder would confuse the database whenever it tried to access information for output. Even so, it vastly simplified the amount of time spent looking for specific projects and enabled faster work flow during the day.
The last firm I worked at was actually a design firm, and I guarantee it had a database of common blocks, title blocks, and project folder creation. The difference in the two firms was that I had no hand in the creation and maintaining of the database, since a more qualified technical team operated that for the entire company. This makes sense, since my last company was a world-wide company and letting a co-op mess around with company standards probably would have had more of a negative affect on that scale, as opposed to the PWD office, which was only about a dozen employees or so. However, the databases used at my last firm were of utmost help, enabling title blocks of any size to be created for any project with a simple click of a button. Additionally, various standard CAD details were available online and could be dropped into drawings with all necessary properties with no effort at all. In short, I think databases really help streamline the design process, by ensuring everyone drafts at the same standards with ease and speed.
Comments
Anthony: I found your post extraordinarily information. I don't know very much about databases function and had no idea the difference between object oriented databases and relational databases. Your post was able to break down the differences in each in a simple manner and helped me understand a bit more of the fundamentals of database design.
Angie: Your discussion on the use of databases in construction is quite detailed and got me thinking about how much the industry has changed over the last several decades with the developments. Much like we discussed in class about Revit eliminating the need for drafters in favor of more skilled workers to manage a model, databases are slowly reducing the need for people to look up cost estimates in a book and instead creating the need for people to accurately program databases. While a good database drastically reduces the amount of work in cost estimation by allowing a single person to plug in the materials/labor/unit items etc., they only work as well as the people that actually write and code them. I wonder if a point will ever be reached in which cost estimation database development plateaus, and databases cannot get any better. Then the only work on them would be to update the inputs with different numbers and costs and let the machine do the rest.
Santiago: I thought your discussion on flat vs. multidimensional databases was interesting. I have a friend who has on multiple occasions tried to explain database computer programming to me, and I just never seem to get it. The idea that CAD files, spreadsheets, and the like are "flat" makes much more sense, since they can physically be represented in a single table. Adding other dimensions (parameters) makes the file much more complex, similar to the many layers in a GIS database, or the families in Revit.
No comments:
Post a Comment