Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

correct some spelling errors (docs/purpose.txt)

  • Loading branch information...
commit 23b700148807a0d61bfe0148dbe28fc6f3d72d60 1 parent 3d6209e
Barak A. Pearlmutter authored
Showing with 11 additions and 11 deletions.
  1. +11 −11 docs/purpose.txt
View
22 docs/purpose.txt
@@ -14,23 +14,23 @@ appropriate for every storage situation (we still have files and hashmaps, after
and in particular the current SQL products available, present problems for large scale software.
But first lets review what is good about the relational model:
-1. It seperates data from look-up strategy, queries are declarative
-2. It is increadibly flexible--most desirable data operations can be expressed in relations
+1. It separates data from look-up strategy, queries are declarative
+2. It is incredibly flexible--most desirable data operations can be expressed in relations
The problems with current RDBMSes are the following:
1. Building a website on a centralized database combines the two worst enemies, disk io and network io, for every
server in the system, and centralizes them onto a single machine. This is clearly not feasible.
2. The relational model does not parallelize well, due to the difficulties of sharing state. Most databases favor
consistency over performance (2PC). You can't have both.
-3. SQL sucks for application developement. Most web apps are programs that construct little sql statement mini-programs
+3. SQL sucks for application development. Most web apps are programs that construct little sql statement mini-programs
by concatenating together strings. This completely ungainly. SQL is vender specific so you are tied to the vendors
-database. This means development suffers emensely. Unit testing any piece of code that involves database access is quite
-problematic becuase the unit test will be slow and will depend on a server running on another maching which can't be
-bootstraped as part of the test code. This could easily be solved if vendors provided a light-weight drop in
+database. This means development suffers immensely. Unit testing any piece of code that involves database access is quite
+problematic because the unit test will be slow and will depend on a server running on another machine which can't be
+bootstrapped as part of the test code. This could easily be solved if vendors provided a light-weight drop in
replacement that could be used for testing. Approximately 10000 products attempt to work around this problem
-by automatically mapping your application to sql. This has been called the vietnam of computer science (refering to the
+by automatically mapping your application to sql. This has been called the Vietnam of Computer Science (referring to the
American war, not the country...and of course computer scientists are not particularly interested in this problem as
-it is too pratical).
+it is too practical).
To begin to understand the problems with relational databases, let's first review some basic facts
@@ -54,9 +54,9 @@ our greatest enemy followed by the network. We can iterate over XXX items of an
look-up a single item via a log(n) b-tree index. We can iterate over YYY items in the time required to complete
a mysql request.
-The relational model is great, when accessed programmatically, but it is best for little applications (of which ther are many).
+The relational model is great, when accessed programmatically, but it is best for little applications (of which there are many).
-In a high scalbility scenario with a shared db, the advantages of the relational model disappear. No longer do you have
+In a high scalability scenario with a shared db, the advantages of the relational model disappear. No longer do you have
flexibility, what you have is a system in which most operations will bring the database to its knees along with
everyone depending on it. Think about the average table, of the set of possible queries, only a few can be issued without
difficulty. With this being the case, the abstraction of the lookup structure becomes a major problem--it is impossible to
@@ -72,7 +72,7 @@ simple puts and gets, and each operation goes first to the cache and then to the
faster than the db, but it can be distributed whereas the db cannot.
There are two basic caching strategies
-1. Local read/write with background repication
+1. Local read/write with background replication
2. Remote access
In the first strategy we try to keep each object on each server. We read and write to the local cache, and in the background
Please sign in to comment.
Something went wrong with that request. Please try again.