https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=WebFund_2015W_Lecture_12 2026-05-12T22:19:38Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=WebFund_2015W_Lecture_12&diff=19937&oldid=prev 2015-03-04T22:43:17Z

<p></p> <a href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=WebFund_2015W_Lecture_12&amp;diff=19937&amp;oldid=19878">Show changes</a>

LeeCroft https://homeostasis.scs.carleton.ca/wiki/index.php?title=WebFund_2015W_Lecture_12&diff=19878&oldid=prev 2015-02-23T17:27:50Z

<p>Created page with &quot;==Video== The video from the lecture given on February 23, 2015 [http://homeostasis.scs.carleton.ca/~soma/webfund-2015w/lectures/comp2406-2015w-lec12-23Feb2015.mp4 is now ava...&quot;</p> <p><b>New page</b></p><div>==Video==<br /> <br /> The video from the lecture given on February 23, 2015 [http://homeostasis.scs.carleton.ca/~soma/webfund-2015w/lectures/comp2406-2015w-lec12-23Feb2015.mp4 is now available].<br /> <br /> ==Notes==<br /> <br /> ===On-Screen Notes===<br /> <br /> &lt;pre&gt;<br /> Lecture 12<br /> ----------<br /> <br /> Midterms to be returned Wednesday<br /> <br /> Today: MongoDB and databases<br /> <br /> <br /> Parts of a web application:<br /> * Front End: client-side code (HTML, CSS, JavaScript)<br /> - runs in the browser<br /> * Back End: server-side code<br /> - web server: PHP, Python, Java, *JavaScript* (node)<br /> - database: MySQL, Oracle, PostgresQL, MongoDB, ...<br /> <br /> Early web servers just used a filesystem<br /> - good for static content<br /> - bad for concurrent access<br /> <br /> <br /> Why concurrency?<br /> - many different web clients trying to modify the &quot;same&quot; resources<br /> - e.g., passwords stored in a file<br /> - *really* bad when using multiple web servers<br /> <br /> Databases are good at<br /> - fine-grained data concurrency<br /> - not as easy to &quot;scale&quot; (cause concurrency is hard)<br /> - that&#039;s SOMEBODY ELSE&#039;s PROBLEM<br /> <br /> Why not just have web clients talk to the database?<br /> (cut out the middle man)<br /> - security: don&#039;t want all clients to access ALL data<br /> - databases do have access control but generally not suitable for most web applications<br /> - also, data validation<br /> - scalability<br /> - databases are relatively slow<br /> - often stick a caching layer in front/separate out static content<br /> <br /> <br /> Types of databases<br /> ------------------<br /> SQL versus NoSQL databases<br /> <br /> Actually, many kinds of NoSQL databases<br /> <br /> Difference is *transactions*<br /> <br /> <br /> SQL =&gt; relational databases<br /> <br /> Data is divided into tables<br /> <br /> tables have columns (fields) and rows (records)<br /> <br /> Columns have types (date, string, number, etc)<br /> <br /> Table for customers<br /> fields (columns)<br /> - Customer ID (primary key)<br /> - name<br /> - street<br /> - city<br /> - province<br /> - etc.<br /> <br /> Table for invoices<br /> - Invoice ID (primary key)<br /> - Customer ID<br /> - what they purchased<br /> - amount<br /> <br /> <br /> Relations connect tables<br /> <br /> Relations often work best with unique keys<br /> - fields where every record has a unique value<br /> <br /> <br /> Scenario<br /> - creating first invoice for a new customer<br /> - problem: system crashes after adding the invoice but before adding the customer&#039;s info<br /> - transaction is what makes sure this never happens<br /> - if just an invoice or a customer change, transaction is not complete and data is thrown away<br /> <br /> Transaction:<br /> - start transaction<br /> - make your changes<br /> - add the invoice<br /> - add the customer<br /> - commit transaction if all changes succeeded, otherwise abort<br /> <br /> Relational databases have *overhead* and *complexty* and *security issues*<br /> <br /> <br /> NoSQL =&gt; no transactions<br /> <br /> We&#039;re using MongoDB<br /> - &quot;document store&quot;<br /> - i.e., JSON store (Technically, BSON)<br /> - no built-in relations<br /> - however, MongoDB can run code...JavaScript<br /> <br /> In SQL databases<br /> - fields are pre-defined and relatively rigid<br /> <br /> In MongoDB<br /> - can have any properties in any document<br /> - no consistency requirement<br /> <br /> Indexing<br /> <br /> <br /> - records/documents are stored in order of primary keys<br /> - fast to find by primary key<br /> - what if I want to find records/documents by something that *isn&#039;t* a primary key<br /> - e.g., invoices by what was purchased, customers by city<br /> <br /> basic search<br /> - if sorted, then you do binary search<br /> - maybe store so you can index into an arry/hash table<br /> - otherwise...exhaustive search<br /> <br /> Indexing is a way to get around exhaustive search<br /> <br /> An index is a data structure associating:<br /> * a field or fields with<br /> * the primary key<br /> <br /> Index by city in customers<br /> - sorted list of cities and customer IDs<br /> <br /> Why not index on every field?<br /> - space<br /> - time of insert/add operation<br /> <br /> &lt;/pre&gt;</div>

Soma