Bases de Dades: introduction to SQL (indexes and transactions)

Transcription

1 Bases de Dades: introduction to SQL (indexes and transactions) Andrew D. Bagdanov Departamento de Ciencias de la Computación Universidad Autónoma de Barcelona Fall, 2010

2 Questions from LAST WEEK Last week Goals Logistics Exam expectations Exam: Tuesday, November 30th. Exam expectations? Practice exam questions? Altering, deleting and dropping questions?

3 Goals for today Last week Goals Logistics Exam expectations Our goals for today s session are: review material for exam, if necessary; review the logistics for remaining classes; see how indexes can be used to speed up access; and start looking at how transactions work.

4 Homework and exam Last week Goals Logistics Exam expectations Solutions to the practice exam are online. I hope to have grades for last assignment online tomorrow, as well as solutions. The EXAM is scheduled for the 30th of November. You will be allowed to refer to a single page of notes during the exam. Why on earth would I memorize something that I could easily look up in a book?! -A. Einstein

5 The course calendar Last week Goals Logistics Exam expectations Remaining problem sessions: 23 November 2010, 30 November 2010 SQL Exam 14 December January 2011 Triggers 25 January 2011 Stored procedures Remaining practicum sessions: 18 November 2010 Scheduled 25 November 2010 EXTRA DAY 9 December 2010 Scheduled 13 January 2011 Scheduled 20 January 2011 Scheduled IMPORTANT: No practicum on the 2nd of December. No problems or practicum between 14th of December and 12th of January.

6 Expectations: any questions? Last week Goals Logistics Exam expectations E/R diagram conventions. Boxes, ovals and diamonds (rhombuses). Underlining keys, etc. Implementation versus E/R description. A single E/R diagram admits many implementations. You should know, for example, when to use a table to represent a relation. Queries: Basic forms: INSERT, SELECT, CREATE TABLE Details: Data description language in CREATE TABLE, including key constraints. Joins: Create and interpret JOINs over multiple tables. Misc (today): ALTER TABLE, UPDATE, DELETE, DROP TABLE To summarize: you should be able to move back and forth between E/R description and SQL, and to perform and interpret complex queries against an SQL implementation of a relational database schema.

7 The schema Creating indexes Consider our re-factored Country database: And recall that we originally wanted to use databases because they are efficient.

8 But fast it is not... Creating indexes But, recall our TEMP VIEW example: CREATE TEMP VIEW Lang AS SELECT main.languages.id,old.country.code,old.country.language FROM Languages JOIN Old.Country ON main.languages.name=old.country.language; CREATE TEMP VIEW Count AS SELECT main.country.id,old.country.code,old.country.language FROM Country JOIN Old.Country ON main.country.code=old.country.code; CREATE TEMP VIEW Spoken AS SELECT Lang.ID,Count.ID FROM Lang JOIN Count ON Lang.Language=Count.Language AND Lang.Code=Count.Code; Selects on the final Spoken table are slow.

9 Why? Creating indexes Why are these queries slow? Well, a naive implementation of the JOIN algorithm is not very efficient. In fact, it is quadratic in the number of rows (in both tables). And the DB knows nothing about the contents of our tables (other than types). Basically, we need to tell the DBMS which columns are important for retrieving results. We do this by creating INDEXes.

10 Adding and deleting indexes Creating indexes To create and index, we use the CREATE INDEX command: This creates an index on one or more columns from a table. This can greatly improve query performance. are deleted using the DROP INDEX command. Rule of thumb: consider creating indexes for things that appear on the left side of SELECTs. That includes WHERE clauses and ON clauses of JOINs.

11 But beware... Creating indexes You might be tempted to just add indexes to every column and not worry about it after. However, indexes can take up a LOT of space on disk. And adding an index adds a small, but important, overhead to ALL subsequent INSERT commands. So, only index those columns that really need to be indexed. In general, PRIMARY KEYs should be indexed (indeed they usually are indexed automatically). And this include composite primary keys like in our IsSpokenIn table (two foreign keys).

12 The need for speed Controlling transactions In the first part of the lecture, we saw how adding an INDEX can greatly speed up queries. Is this the only case where queries can (or need to) be sped up? Well, no... Recall our first, mono_country.sql database? Why was inserting the initial contents of the DB so slow? And can we speed this up?

13 Atomicity and transactions Controlling transactions A DBMS must guarantee atomicity of all basic commands. That means that it guarantees that during the execution of INSERT, SELECT, etc., no other commands will be executed at the same time. This is so that the contents of a table cannot change while a command is executing. Guaranteeing atomicity is expensive, though. Every atomic command must ask for a lock, get it, lock the database, execute the command, and release the lock. You might have seen this when sqlite3 created a *.journal file while executing.

14 It gets worse... Controlling transactions Actually, in addition to guaranteeing atomicity, a DBMS must guarantee atomicity, consistency, isolation, durability. These are commonly known by the acronym ACID. Essentially these also implies that if something goes wrong in a command, the database will never be left in an inconsistent state. This requires a lot of bookkeeping while processing queries, and this bookkeeping is encapsulated in a transaction. In our example, the DB is working very hard to guarantee ACID for every INSERT. It creates and executes more than 1000 transactions.

15 Rolling your own Controlling transactions SQL allows us to control transactions. We can control when a transaction is started and when it is finished. We can also control whether a transaction should be committed. That is if the changes to the DB should be made permanent. SQL gives us very fine control over how transactions are handled. With transactions we can perform complex error handling and recovery.

16 But that wasn t the point Controlling transactions An added benefit is that we can control how many transactions are created, and when. This can have a tremendous affect on performance. To initiate a transaction, use the BEGIN TRANSACTION command: And end it with COMMIT (or END TRANSACTION): (demo)

17 Key points Key points Exercises Exam: Tuesday, November 30th. can be used to greatly speed up some queries. They allow fast access and comparison to column data. should be added to columns that frequently appear in WHERE and ON clauses of queries. They trade disk space for speed, so be cautious. can also be used to speed up some operations, but in a different way. gives you control over atomicity of commands.

18 Exercises Key points Exercises None. Study for the exam.