Posted by Erland Sommarskog on 07/15/07 17:52

raylopez99 (raylopez99@yahoo.com) writes:
> As for CAM/Pointers architecture versus RDBMS architecture, I'm sure
> some smart engineer could figure out how to make the former work.
> They already use CAM architecture for routing internet packets, so I'm
> sure they can figure out a way to do double entry accounting (that is,
> update cash-holdings account when debiting withdraw, etc).

As always, there are more than one way to skin the cat. There are more
possibilities to maintain data integrity than relational databases. But
it is a complex matter, and relational databases has proven to do a
decent job of it.

> Rest of your points are well taken. It probably does take a lot of
> time to search a 30 GB RAM memory, even with a quad core Intel uP.
> Perhaps RDBMS will always be faster for real-time transactions, which
> seems to be where they are used.

For true real-time, you may want to use something different, maybe in-
memory. But for all that happens after, all the analisys, the archiving,
the invesitgation of went wrong, trends, a relational database maybe
with an OLAP engine on top is the overall dominating solution today.

> As for data entry, I was simply saying with RDBMS it seems you have to
> expend effort in getting the right data into the right field (i.e.,
> cannot enter a Char into a date field, etc). So some "energy" has to
> be expended to do this, moreso than a flat file, which can be more
> free-flowing.

Nonsense. You can declare all columns in a RDBMS to be character if you
like. You can skip all validation. You can even skip having multiple
columns, but have a single wide text column for all data. Right data into
the right field has nothing to do with relational databases, it has to do
with business requirements. If you have an order, you don't want the
customer and the employee to took the order to be mixed up, do you?

> So I suppose employing cheap Indian or Chinese or Swedish housewives
> to do "data entry" is a small price to pay in order to get data in the
> right format so you can use it efficiently.

Actually a lot of data entry in many systems comes by loading data
from other sources. For instance, in our system, the main bulk of the
transactions comes from the stock and option markets. Yet others are
created by the system itself from various rules. (E.g. interest
capitalisation). I would not expect as much as 5% of the transactions
are manually entered.

> I entered the parameters I wanted into the query, and it
> worked (I was entering a new row in my Authors dB--which also gave
> rise to a new question, kind of trivial, but why the new row is
> automatically numbered with a successive number that does not repeat
> even when you delete the new row later and run the query again... must
> have something to do with a "seed" of some sort.. that is, after the
> "3rd" row is entered, and I manually delete the row, the next time I
> run the query the new row is not "3" but 4. And if I delete again,
> the next time the new row is 5, not "3". And again, the autonumber
> becomes 6, not "3", etc. Not a big deal but I'm curious as to
> why...must be some parameter that's akin to "consecutive renumbering"
> for new rows).

It appears that your table has the IDENTITY property, and it is an
inherit characteristic of this property that it gives you gaps. If you
want consecutive numbers, you should generate your surrogate keys yourself.

The reason IDENTITY gives you gaps, has nothing to do with relational
theory per se, but it's all about concurrency. The design permits very
many concurrent inserts being carried out.

--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

[Back to original message]