Monday, February 8, 2016

B5 - SQL - Farnelli

Databases are meant to allow users to efficiently access the data stored in them. SQL is the language behind how information is accessed in many databases, and is important because of how widespread its use is and how it can be integrated into a user’s experience. Unlike other types of data storage which involve nested items and data trees, SQL primarily locates data in tables. The fields of the tables can then be used to sort the data and access specific entries. Tables can be related to one another, such as a table of products and their attributes and another of suppliers and a third of product orders. One reason why so many people dislike SQL is because it is geared only toward this type of information storage, and is not readily changed or reinterpreted. However, the purpose of the language is fulfilled by how it is structured. For example, in the figure below from the Wikipedia page the purpose of the statement is to find the USA entry and increase the population by one. 
Figure of sample statement in SQL
To do this, the user first states what they are aiming to do (update information), where this update is located (in a country table), describe the change (increasing the population) and direct the change (only where the country name is USA). This seem to be a very roundabout way of making this update, but often these changes are made with a graphical user interface or more user-friendly dialogue box, with the coding dictated by what the user enters into the search box, etc. The way users interact with Revit’s databases are similarly structured, which I will discuss. The language was not necessarily written with coding in mind, but with efficiently accessing information from a large set of tables. This can be altered easily to tailor it to a different set of data by changing the parameters which are being referred to in the commands, though this may require work upfront. 

A database needs to be able to be created, read, updated, and deleted (CRUD). In Revit, we see examples of these capabilities in the assignment we completed last week. Most of the libraries come already created, but we were able to create families that added their attributes to the database. Every time you add an instance of this bookcase or of a wall, door or any other item you are reading from the stored information. Updating a piece is also very easy, as you can either edit a family file and reload it into the database or make a duplicate of a family or type and edit attributes. Deleting families is also relatively simple using the same “edit type” dialogue which allows you to duplicate a family. While these may seem like trivial tasks, they are important in the way the allow the information to be stored and accessed quickly. Even if only one person in a group knows how to create a family, most can place it in a model and view its dimensions, etc. By linking the information together, it also becomes more easy to find which piece you need. For example, in Revit you are given a ribbon which allows you to pick what sort of element you want to place (for example a wall). Then you can choose what specific type of wall you want to place based on the attributes (thickness, fire proofing, etc). By doing this you are accessing what Autodesk considers the most relevant aspects of the item before placing it. Without this built-in database query, you would have a much more confusing experience. Instead, the way you interact with the program guides you through the stored information in a way which is understandable. 

Sources:
http://www.thesitewizard.com/faqs/what-is-mysql-database.shtml

Comments:

Kai Waechter: I agree that SQL is important because it is generally the way in which a user interacts with a database. Data is very important and present in today's world, from databases of information about products to the database that holds all of the information of this blog. Having a unified (or at least mostly unified) language behind accessing this information is very important for interoperability and information exchange between databases.
Dianna Vogel: I agree that the coding behind SQL may seem primitive, and this is likely a holdover not only of the age of the language but also of the original use. When it was first invented the amount of data being used in a particular program was not nearly as large as what is used today, and the first uses were likely not web based. Today's use of databases to store so much more information is much more complex and contains many more categories and tables, which is likely why the language seems so cumbersome. The first databases were along the scale of a large Excel sheet, not a set of data which requires a set of servers to hold it as today's do.
 

1 comment:

  1. Cathlene,

    I have never worked with SQL before but by reading your blog, I can imagine how such programming language can be used to obtain specific family sets from a big REVIT family database. Also creation of new family sets can be organized and manipulated to ease of use during extraction by other parties such as contractors, architects and structural engineers who are working on the same platform.

    ReplyDelete