Databases: Journal 4

 Summary and Questions

So far, in this database class we have learned how to not only create database, but also how to manage them. One of the coolest concepts I came across was using Views. I can very much see myself using this ability this ability in SQL when administrating my own databases on my personal and profesional projects. On the creation side of things we also learned how different tables interact without each other through foreign keys. The ability to be able to declare a table's column field as needing a value through NOT NULL pretty much, in my opinion, is one of the pillars of strengths SQL gives us. On top of this, when we learned about the ability to create a union through UNION in SQL I saw the great possibilities there. In all honestly though, SQL is a very simple language, the complexity rests with the schemas. The ability that we have learned in designed our own diagrams arguably is more important than the SQL language itself. The diagrams really show us the design and idea that went behind and entire database.

That said, there is three questions that I have that have not been answered in the class so far:

1. How exactly do other programming languages, fore example JavaScript interact with an SQL database?
2. Are most database designes in the real world built up of just a few tables, or are most databases extremely complex?
3. Is there a specific code style that is preferred when naming things in SQL databases (e.g. snake, camel)?

Databases: Journal 3

Non-key column

3NF essentially is a normal form that drastically helps reduce the amount of duplicated columns in tables. When queries are performed, less data is processed because there it is not being duplicated across multiple tables; this makes performance faster, but requires detailed planning to implement correctly.

SQL View

SQL view is a feature in SQL that allows visualization of data in a unique way. Most of the time when performing queries users are combining different data from different tables to get a better picture of the stored data. SQL view like traditional tables, also allows to populate data, however, with a view, the user is able to, in a sense, "save" commonly used columns for future refers. Essentially, views are similar in that they help visualize data, but they differ in that that it's data that can be referenced in the same way, multiple times in the future.

Databases: Journal 2

SQL has the flexibility to join tables on any column(s): Think of example where joining on something other than keys would be needed.  Write the query both as English sentence and SQL.

Being able to join two tables is extremely useful in SQL, in fact that is probably where the languages strength is at. Sometimes however, you may need to join two tables that aren't necessary related. This is where something like UNION would come into play. With union, for example, say you can have a table that relates to employees and another to customers. With union, even if employees and customers don't relate to each other in anyway. You can still get a full list.

Example: SELECT * FROM customer.customername UNION SELECT * FROM employee.employeename

On the SQL language: What do you think of SQL as a query language?

From my experience using SQL so far, I am starting to not really be a fan of it. To me, some of the syntax just feels like talking to one of those call robots when calling a business; it simply does not feel intuitive. What I am having most trouble with is that in previous languages like Java, for example, everything was very step 1, step 2, step 3 like. However, SQL to me seems very vague, perhaps I just need more practice...

 

Databases: Journal 1

1.  Relational database and spreadsheets on the surface may seem similar, however, there are some key differences that cannot be ignored. For one, a relationship database has a primary key that is unique to identify and programmatically fetch data, spreadsheets do not have this. Another differences are when it comes to columns, in a spreadsheet, columns can have any data and do not have to be uniform, this is not true in a relational database where all the columns have to be uniform.
2. Using a relational database allows us to programmatically pull and update data, without being able to do this, it would be really difficult to have a uniform way of changing data since files can be arranged in a different manner that is not always uniform. Additionally,  relational databases help us create relationships between data.
3. I mostly want to learn the inner workings of beautiful front ends that we see in applications today. How all that data is stored and then retrieved in a elegant way through programming.