Ask Slashdot: Learning DB the Right Way; Books, Tutorials, or What? 106
An anonymous reader writes "I have deep experience programming in many languages, and I've some exposure to SQL through PostgreSQL. My math goes so far as trig and algebra, with a little statistics. So far, I've learned enough to be dangerous: mostly via other people's code, experimenting, the PostgreSQL docs, etc. I've been successful using the DB in various ways, but I know I am missing a great deal (and probably doing it wrong, at that.) When DB articles come up on Slashdot, I don't recognize a good deal of the terminology. What is the best way for a technical person to learn SQL/DB work using PostgreSQL? Books? Tutorials? I should mention I don't have local access to a university or people with DB knowledge; have to do this on my own, so books or the Internet are pretty much my options."
No Obligatory XKCD (Score:5, Funny)
Oh well, goes along with the theme:
http://geekandpoke.typepad.com/geekandpoke/2011/01/nosql.html [typepad.com]
Re:No Obligatory XKCD (Score:5, Funny)
once he has put on a db here's a handy reference http://howfuckedismydatabase.com/ [howfuckedi...tabase.com]
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
I agree. I have increased performance for specific tables and queries more than ten times simply by looking at the MS SQL query analyzer. Often it will even give you the SQL you should run to create the index it thinks it needs. Sometimes it requires more thought than that, bu
Re:No Obligatory XKCD (Score:5, Insightful)
No business cares about which database performs how well per unit of clock cycle. They care about how well does it perform per dollar. The fact that you are paying about 3-10x the hardware price in licensing costs means that you can come in and throw a lot more hardware at a problem and solve it for less money simply because the database technology is 'free'. This is the dominant reason people go with FOSS. Not because it's better but because it's good-enough and they can spend a few extra integrating it and having consultants for support and not be strapped over a barrel when Balmer or Ellison decide they need to buy another sports team or yacht respectively.
Example:
A single dual socket, octo-core (16 total) core box to run SQL Server will cost you about $10k from dell depending on config. It will cost you another $1000 for Windows Server (at least) and then another $110,000 (6,874/core x 16 cores)for enterprise edition (plus support!). You can buy 12x the hardware for MySQL than you can for SQL Server. There are reasons you would go with Windows, but don't scoff at people making money by replacing MSSQL with MySQL, they do exist and it's a very real business model. It gets even more fun when you start talking about virtualization and other licensing gotchas that exist with the big proprietary DB vendors.
Re: (Score:2)
No business cares about which database performs how well per unit of clock cycle. They care about how well does it perform per dollar.
They do, because time is money. If a given daily task that takes 30m can be done in 10m, it is a matter of cost. Also, throwing hardware at it increases operational costs - increased complexity to maintain, electricity/ HAVAC, etc.
As for your example, it is flawed - if you truely believe that you can replace SQL Server Enterprise Edition with MySQL (when you actually need the enterprise features - or actual SQL features), well... go ahead - it would be fun to watch. Since most MSSQL users don't need the
Re: (Score:3, Interesting)
As someone who has done a fair bit in mysql, mssql, and pgsql over the past 15 years, mysql is not anywhere close to the product mssql is. That being said, pgsql has become quite a bit better than mssql recently in many ways. So probably my current ordering, from best to worst, for my most common use case (web application data tier) is: pgsql, mssql, mysql
Now, of course it depends on the application! MSSQL has some pretty nice strategies for replication and multi master stuff that you just can't do with
Re: (Score:2)
"not that I use any database as much more than dumb storage"
Which is the right thing to do. Embedding business logic in your database is an anti-pattern. Basically the same as mingling your model with your controller.
Re: (Score:2)
Depends on what you mean by embedding. The stored-procedure engine of an RDBMS is really a separate system that happens to reside in the same software stack as the data access portion. There's nothing wrong with embedding business logic in SPs, especially if you have multiple systems accessing the DB. In that scenario, you don't have a single point of access other than the DB which can act as a controller.
And, as with most design patterns, they work great until they don't. Being able to realise when the
Re: (Score:2)
I think modern developers have a very fuzzy idea of what "business logic" means. I model business logic all the time in my databases, completely without the use of stored procedures (or even custom functions for the most part). Just the fact that you use a foreign key constraint happens to be business logic, and it *absolutely* belongs in the database.
This idea that a database is just an adjunct to the application only works for startup companies or lightweight web applications. Once you have a mature compa
Re: (Score:2)
Thanks for that site, awesome.
Re: (Score:2)
Also, thanks for that. As an ex Slony user, I appreciate that reference!
The answer hasn't changed for decades (Score:5, Informative)
Date, An Introduction to Database Systems
Re:The answer hasn't changed for decades (Score:4, Informative)
Re: (Score:1)
As a dba for over 40 years and having worked on almost all the major db systems around (and some that are no longer with us) I can totally recommend the Date/Codd books on db theory. They have it all. What they don't have about some specific system you can get from the vendor documentation or via online searching. I still have my original 1971 edition of Date & Codd's book on db systems.
Re:The answer hasn't changed for decades (Score:5, Insightful)
Yup. Date is the One True Source.
That said, when I found myself in a similar situation to the OP, here is what I did and found: 1) Read Date. 2) Make some toy databases. 3) Go back to 1 for a few iterations. At the point where I needed to deploy a database at work, I was able to do two things: a) convice my boss to hire a database expert, and b) have a strawman design for a database to go along with a spec when the expert came on board.
I learned that database experts learn to be very good at diplomacy :) I learned a huge amount from her as she showed me how to work up a better design and show me why it was better. Of course, that is why I hired her.
After reading Date and making toy databases I had the fundamental concepts, but lacked the practical experience to make good choices in how to normalize the database. How you normalize impacts performance, maintainability, and ease of maintaining data integrity. So bottom line is I found that self-teaching database design got me to something useable, but like many other things in software, the fastest way to learn is to make friends with a smart cube neighbor.
Re: (Score:1)
$170! Holy Cow that is an expensive book
Re: (Score:1)
It's an upper-division textbook. On the other hand, if you want to know WHY you should probably be using an RDBMS for most of your application problems, this is the book to get.
I have the 8th edition, and although the book could do without some of his more opinionated footnotes, the entire text from front to back is absolutely rock-solid relational database theory.
Re: (Score:2)
If your career will involve databases for any length of time, it will pay for itself many times over.
Re: (Score:2)
And Gray, "Transaction Processing: Concepts and Techniques".
Re: (Score:2)
That's the one I learnt from in 1987. Relational databases haven't changed that radically since then and the knowledge is applicable to any implementation of them.
Stanford Introduction to Databases (Score:5, Informative)
Keep in mind though: this is a full fledged college class, not some sort of YouTube tutorial or anything like that. If you want to follow it properly, be prepared to spend some time a week doing homework and following lectures.
Re: (Score:3, Informative)
The class isn't in session but you can still work through all of the coursework on Coursera. https://www.coursera.org/course/db
Re: (Score:2)
Another starter resource (Score:4, Informative)
Re: (Score:3)
Same as with learning any big subject (Score:1)
A little of everything, with emphasis on hands on experimenting. Or a lot of everything, with big emphasis on hands on experimenting.
You won't learn all you need to know in a week, despite the pitches made by the books and boot camp courses.
There is no One True Way (Score:3)
There is no One True Way to learn a language, a piece of technology, etc. It depends on your learning style. One thing a lot of people who come into IT are shocked to discover is the sheer amount of stuff to learn, and the lack of tutorials, classes, etc., that effectively cover it. Many leave for just this reason. The first thing you need to learn in this field is how to teach yourself something, and that means knowing what works best for you. Some people need to write it down. Some people need to hear people talking about it. Some people can just absorb it by osmosis. Some people are global thinkers, others are detail-oriented. Personalities run the gamut in this field, but the one thing everyone who succeeds in this field has in common is that they can learn new information quickly, and on their own.
A lot of people will suggest books here, and that's fine. It may work well for them, and possibly for you. But you need to know what your own learning style is first, before you go much farther, especially if you're branching out into a new field or subfield. The time spent teaching yourself how to learn, and finding your own learning style, will pay for itself far, far more than any book suggested here -- your whole career will benefit.
Re: (Score:3)
girlintraining is absolutely right. Heed her advice: know thyself. With that said, I'm going to give you what works for me and some gotchas I've found in the field.
Some people think they need just a specific answer so they learn by googling for everything and never learn outside of a narrow box. Personally, I find they often don't make good programmers or DBAs. I think a disciplined approach to learning a language or database is a must. The PostgreSQL documentation [postgresql.org] is excellent in that regard. It star
Re: (Score:1)
But as globally unique identifiers they are useless. Where possible I prefer to let people choose what name and title they prefer to use in correspondence with them.
Stanford "Introduction to Databases" on Coursera (Score:5, Informative)
Re: (Score:1)
ANnd Jennifer Widom is the wife of Michael Stonebraker, who is a hard core database dude and also happened to be the one who started the Ingres project, on which PostgreSQL is based.
Fucking Javascript-only site (Score:1)
Subject says all. Not for me.
You haven't told us what you want/need to do. (Score:3)
Are the databases preexisting, and you'll be "just" querying and modifying (inserts and deletes count as modifications)? In which case SQL is "all" (note the quotes) that you need to know.
Or do you also need to design systems? Then you need to know UML, data normalization, access strategies and a dozen other things.
Re: (Score:2)
No matter what you are doing with a DB i would say understanding normalization is the important thing.
Re: (Score:2)
Understanding normalization would help in creating temporary tables used to hold intermediate results during analysis. If your temp tables lack integrity, you could be creating tables with the wrong rows, leading you to the wrong conclusions.
Re: (Score:2)
Then you need to know UML
No, he won't. He'll need a brain, though.
Re: (Score:1)
Re: (Score:2)
What? Keeping total on invoice is non-normalized (redundant data, violates 3rd). You supposed to total up line item every time you want invoice total. Fanatics will say lineitem shouldn't even have price, it should just join to pricing history.
Re: You haven't told us what you want/need to do. (Score:4, Interesting)
Someone once told me "Normalize until it hurts, then denormalize until it works."
Re: (Score:2)
Fanatics will say lineitem shouldn't even have price, it should just join to pricing history.
That's basically impossible once you hit the "Amazon" level of item count and algorithmic price adjustment.
Even in simpler cases, it makes sense to store what you charged that customer at that time for that item. Normalizing that sort of data makes sense, though, so you have an "Invoice" table with a key (like the invoice number) and a "InvoiceLines" table with each line referencing an invoice. That kind of normalization makes it easy to answer questions like "how much did we charge for that item (on aver
Re: (Score:2)
What should it link to for a manual override entered directly onto the invoice?
Re: (Score:2)
A discount % is what the fanatics will say. I'm not one of them, but they are everywhere. I agree with the sib, lineitem should record price charged and discount given. Invoice should record price schedule used. By the magic of definitions it's not redundant data.
This is just to be 3rd NF.
Re: (Score:2, Insightful)
normalized databases come naturally
Not sure about that. I keep on thinking database design is easy (having worked with them for over ten years). Its just a case of working out if entities have a one to many or many to many relationship usually.
Then I get asked to "take a look" at some PhD students design, and realise how unnatural it is to some people.
Re: (Score:2)
On the other hand, some things that seem simple and obvious (version your database, make backups) seem to be like rocket science to some people. I'm not sure why.
Re: (Score:2)
I've met more than one very good developer who didn't grok database design.
One subcontracted me to teach his girlfriend who needed it for a course she was doing. Basically, it involved us all going to the pub and talking about movies and music while she scribbled furiously. It's a good teaching example because it involves natural/surrogate keys (how do you deal with movies/bands/artists with the same name, or movies with more than one title?), multiple relationships (an actor might also direct, a musician
Set Theory (Score:1)
To the extent that set theory is important, I would recommend reading Applied Mathematics for Database Professionals (which I'm reading right now). It very carefully builds the ideas of set theory which seem necessary to work with relational DB's, one step at a time. Some of these same concepts also appear necessary if you ever want to work with graphs/lattices/big data, etc. If you've ever done a truth table, you're already mildly familiar with it.
From the book ...
It is a common misconception that the w
Re: (Score:2)
But remember that SQL queries are bag operations rather than set operations. You have to hack the scripts to ensure set operations.
It's not that complicated (Score:4, Informative)
It's not that complicated.
In the SQL world, data is stored in "tables". Each table consists of "rows" of "records". Each record has "fields". Each field has a "field name" and a fixed "type", like TEXT, INTEGER, or DATE. Tables are created with the CREATE statement, where all the field names and types have to be specified. So that's what SQL data looks like. That part is fairly simple.
Tables start out empty. Data is added to a table using the INSERT statement. Existing records can be changed with the UPDATE statement. The SELECT statement is used for searching.
What makes SQL useful is that searching is very powerful. One SELECT statement can look things up in more than one table, find matching items, sort, summarize, and extract specific fields. The key to understanding SQL is learning what SELECT can do. On the other hand, if all you need to do is find one row of a table based on one key, the SELECT statement for that is very simple.
Tables have "indexes". If you use a SELECT statement with a search request for which there is no helpful index, the entire table will be linearly searched. This is slow. So you specify which fields need an INDEX to speed things up. This is usually done when the table is created with CREATE, but it can be done later. When looking things up with SELECT, you usually don't have to mention indexes; which index to use and how to use it is figured out by the database system.
SQL databases scale up well. Gigabyte-sized tables are normal. Terabyte-sized tables are not unusual. You can have many queries and updates running on the same table at the same time. The database system handles all the locking for you. Some database systems can be run on clusters of machines, and some support multiple redundant copies. You can do a lot of things while a database is running that you wouldn't think of as being possible. You can add a new index, or even a new field, to an existing table while the database is in use. There's a lot of heavy machinery behind the scenes to make all this work.
All the major databases try hard to maintain data integrity. A machine crash and restart will not damage any serious modern database. Program crashes are handled, too. A group of SELECT, INSERT, and UPDATE statements can be blocked together as a "transaction". The database doesn't change until a COMMIT statement is executed, and then all the changes take effect at the same time. If something goes wrong, like the program crashing or even the machine crashing before the COMMIT, the database is unchanged. If your program detects an error and needs to abort the transaction in progress, it does a ROLLBACK and the database is as it was before the transaction started. There's a lot of heavy machinery behind the scenes to make all this work.
There are security features. Access to tables can be restricted, in some cases down to the field level. Databases have user accounts, which are not necessarily tied to operating system login accounts. You can have accounts which can only read some tables, not update or delete them, or accounts which can't see some fields of some tables. This is valuable in web applications.
Database programs have libraries which allow them to be called from various programming languages. Programs in different programming languages can talk to the same database at the same time. So you're not locked to a specific programming language.
Those are the basics. Go install some SQL database on your desktop machine and play with it. MySQL, MariaDB, and Postgres are all free and will work on Linux or Windows desktops.
Re: (Score:1)
That and normalisation based on keys to design out duplication of data and remove years of developer pain!
Re: (Score:2)
Some tables have indexes. Some don't. Sometimes it is faster to access rows via an index, and sometimes a full table scan is faster (and in the cases where a full table scan is faster, it will typically be 100x faster than index-to-table access).
I agree with you that getting started is not that hard (you can also down
Re: (Score:2)
Actually. It is complicated. You don't know enough to know that and that makes you dangerous if you were a DBA.
Schemas, OLAP, speed, how to write queries so you actually get the results you were expecting and not some subset.......
Anyone that voted you up either did not think about it or is equally as dangerous.
computerChimp
Re: (Score:2)
Denis is that you?
Re: (Score:1)
ha ha no. I suspect that Denis is a wise man.
Re: (Score:2)
Go install some SQL database on your desktop machine and play with it. MySQL, MariaDB, and Postgres are all free and will work on Linux or Windows desktops.
Or, experiment with SQLite [sqlite.org]. You can download a self-contained standalone precompiled binary that you run as an ordinary command-line program. (ex: "sqlite3 mynewdatabase.db") In fact, sqlite3 is already installed by default on your Mac and probably also on your Linux desktop, so you might not need to install anything at all. There are no servers to set up and maintain and no access permissions and user accounts and passwords to configure. And the database you create is just an ordinary disk file that
Re: (Score:1)
A breif intro (Score:5, Informative)
1) SQL is not a relational database, it is an interface to a relational database management systems, e.g. Postgresql. The "NoSQL" crowd lost me in the first 10 minutes when they showed me they did not know the difference. From that point forward I had a tough time taking them seriously.
2) Date is good but a bit hard to slog through sometimes. Realize that RDBMs are based on actual Math theory. But you don't have to derive the theory so don't be afraid.
3) Normalization is import. Honestly, people talk about the "Object/Relational impedance" and I have never seen it. I have found that if you define your objects properly up front you get your DB normalization almost for free. And if you understand your data properly and do a good job at normalization you get your objects almost for free.
4) Know your database engine. RTM and try various scenarios. Have fun but only on a test instance on a test machine.
5) Know your hardware/VM system. I have found many people blame the DB engine for poor performance when poor hardware configuration is the fault. Learn how to profile.
6) Learn how to profile software as well. Everybody blames the DB engine when performance is poor when most of the time it is their crappy code.
7) Some best practices: http://c2.com/cgi/wiki?DatabaseBestPractices [c2.com]
Re: (Score:2)
1) SQL is not a relational database, it is an interface to a relational database management systems, e.g. Postgresql. The "NoSQL" crowd lost me in the first 10 minutes when they showed me they did not know the difference. From that point forward I had a tough time taking them seriously. ...
If you want to nitpick then do it right. SQL is not an interface. It is a query language: Standard Query Language, well the standard also contains DDL
I guess you simply are not smart enough to grasp what NoSQL is about or
Re: (Score:3)
SQL is not an interface. It is a query language: Standard Query Language, well the standard also contains DDL
Structured Query Language [wikipedia.org], actually.
If you want to nitpick then do it right.
Words to live by.
Re: (Score:2)
True :D it is meanwhile "Structured" ... I think when it was first introduced it was still named "Standard" and I keep mixing this up, lucky this was not an exame ;D
Re:A breif intro (Score:4, Informative)
normalization is mainly used for space reduction, in our days that is far less important than at the time when it was "invented".
Wrong again. Normalization is about data consistency, space saving is secondary (and given the overhead of keys, constraints, indices etc. possibly not true). But the NoSQL crowd also lost me on this point as well. "Eventual consistency?" What does that mean? How about "you will eventually get paid" or "your medical records will eventually show your drug allergies" or "your credit rating will be eventually correct".
But you're right, I was in a hurry I should have said: "SQL is a scripting language used to access an API of a RDBMS".
Re: (Score:2)
"Eventual consistency?" means that in the end the data will be consistent :D pretty simple.
However it is not ment in the way we know it from traditional databases as we are not talking about schema consistency here.
Consistency in huge data means, if you query, regardless which part of the cluster answers your query the answer will be the same.
The background is: lets say you have 100 nodes. And you write data to your cluster. You define in the write "transaction" you accept it as written if 10 nodes have per
Re: (Score:2)
How do you know you are accessing the correct 10 nodes?
Re: (Score:2)
You don't know. That is the point. You accept that for a while your data is "inconsistent".
E.g. you look at my facebook site and your friend does at the same time. For quite a while, perhaps half an hour, your views might be different, one of you missing my latest status. But who cares? Tomorrow you will both see the same data.
Re: (Score:2)
Normalization has almost nothing to do with space reduction. Normalization is there to help ensure correctness of your information.
Re:A brief intro (Score:1)
Normalization is good because otherwise when one of your users gets married and wants to change her surname you realise that every entry in every table that relates to the user has their surname recorded and you have to update millions of rows in twenty different tables and none of it is documented and if you miss updating it any of the tables you might break something important. In a normalised database you change it one place and you are done.
Re: (Score:2)
You know this. I know this. I'm not confident the GP knows this. :-)
A few free resources (Score:2)
Learn SQL The Hard Way: http://sql.learncodethehardway.org/ [learncodethehardway.org]
Use The Index, Luke!: A Guide To SQL Database Performance: http://use-the-index-luke.com/ [use-the-index-luke.com] (my own site)
Source: http://stackoverflow.com/questions/194812/list-of-freely-available-programming-books [stackoverflow.com]
Re: (Score:2)
"Practical PostgreSQL" is from 2002. There are so many things in PostgreSQL that have changed since then, you'd be better off reading a generic database introduction instead of that one now.
I don't know if it is possible (Score:2)
I'm not sure it is possible, today. From about 1995-2005 forward a large amount of database work, and development of applications against databases, was done by people who didn't really have a good grasp of the fundamentals of the concept, the history of its implementation, or a very thorough knowledge of the available technology. The result is that various self-taught paradigms became embedded in an entire generation of developers, and those paradigms have now been picked up and embedded in technology by
The best way is always the hard way (Score:1)
http://sql.learncodethehardway.org/book/
dBase? (Score:2)
Re: (Score:2)
Better db engine then MySQL. Very similar issues. Kids have to learn on their own.
LDAP? (Score:5, Funny)
Here's a stupid question.
Why not put all data into the ldap, next to all the login information etc.
Then you can learn to be a bad ass sysadmin who allows you to login from everywhere AND learn a database at the same time! Many apps like mail clients, server daemons can integrate with ldap! You can do cloud computing : sync your phone contacts to it.
If you're working in a company, tell the boss you now only need the Windows AD domain controller. It's awesome consolidation and cost savings. Also, it's a mature, market leading NoSQL implementation.
Re: (Score:2)
I hope someone has some Funny points left to give your post.
Then again, given what I've seen over the years I'm sure this has been done... More than once.
sPh
Re: (Score:2)
One of the better Dilbert cartoons about the boss wanting to build an inventory system in email comes to mind: http://dilbert.com/strips/comic/1995-12-31/ [dilbert.com]
Re: (Score:1)
Not so much a stupid question as a criminally insane suggestion. Much like how LDAP retains its horror-inducing properties while actually proving true to its "lightweight" claim... compared to X.500.
There really ought to be a middle way between LDAP and NIS. Something combining the simplicity of the latter with the "one question, one answer" architecture of the former.
Anyway, this has exactly nothing to do with learning about postgresql, SQL or relational databases in general.
Re: (Score:2)
best answer.. (Score:2)
Set Theory (Score:3)
The most useful way I have found of thinking in a relatively simple yet robust mathematical way about SQL and relational databases is in terms of set theory.
For example a standard join can be considered as finding the intersection of two sets.
This this level of abstraction should be usable by someone with your level of mathematical training.
Re: (Score:2)
Isolation level and transaction are key concepts as well, ones that many people working with databases miss entirely.
sPh
Re: (Score:2)
You are correct. Access in it's simplest form is NOT a true database in that it is not a first class server of data per se. It can be used in a multi-user fashion though. You have multiple users running Access and a client program which is linked to a common Access database file on the network. All the intelligence except for data validation is implemented in the client. Back in the old days (the 90's), Access did not have row-locking but locked chunks of the database. Concurrency was a major issue an
CHris Date (Score:3)
Chris date has the clearest understanding of databases out there and while most of what he's written is not vendor or even SQL specific (although some of it is too..) his thoroughness, precision and ability to go meta on every aspect of databases is without parallel. Sure, it's not "how to use postgres" but studying him will pay off many many times over during your career when you're "stuck" because a lot of being 'stuck" in this field is not understanding the actual relational model at the conceptual level and when I say "actual relational model" I don't mean SQL, which is one just so-so implementation of the relational model. It's the places where SQL departs from the relational model and the practices that have developed in the community to compensate for that departure - without people even being aware that that's what they're doing - which create the worst and hardest problems.
The Manga Guide to Databases (Score:2)
The Manga Guide to Databases [amzn.com] is the best introduction to (relational) databases I've come across. It provides an entertaining and thorough overview of database terminology and concepts. I've used this book for years with junior engineers and interns who have all loved it, and the DBAs I've loaned it to were impressed by how much ground the book covers.
Learn how to organize data! (Score:2)
Data is nothing but a collection of information. The information itself is unimportant. What is important is how that information will be used. The way information is used is the predicate for its organization.
After you grok that then you can start to learn how electronic systems store and retrieve information.
One of the things that has never let me down is the fundamental understanding of how computers work. Remember that no matter what whiz bang shite you read about, computers do exactly two things:
Read Yoshinori (Score:3)
Read Yoshinori Matsunobu's blog:
http://yoshinorimatsunobu.blogspot.com/ [blogspot.com]
At least, read his first post and view the slide deck:
http://yoshinorimatsunobu.blogspot.com/2009/04/mastering-art-of-indexing-slides.html [blogspot.com]
Database efficiency considerations (Score:2)
Let's see - proper RDBMS considerations:
Proper normalization of data
Efficient keying for relating data. Compound keys can be difficult to work with.
Use of simplest possible recordset type for working with data.
Understanding of boolean logic and sets. Needful for creating efficient SQL queries.
Understanding of a particular RDBMS's optimization techniques/order of operations.
Data validation to prevent GIGO.
Record locking schemes to prevent inconsistent updates - transactions should be used to minimize impac
MIT Open Courseware (Score:1)
What do you mean by learning DB? (Score:2)
Are you trying to learn the concepts (normalization, cardinality, keys, constraints etc) or the hands-on specifics for a specific DBMS?