Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : How high will Microsoft fly? -- Ignore unavailable to you. Want to Upgrade?

To: dybdahl who wrote (52142)	10/24/2000 4:22:34 PM
From: Nick Kline	Respond to of 74651

If your data fits in memory, or you don't need transactional backup, logged changes, guaranteed recovery etc, then you can do better than a conventional relational database. The database requires overhead to make all these things happen. Sounds like your application doesn't need real applications, since you can tolerate the restriction that only one transaction operates at time. Things like tpc-c and peoplesoft and sap would be too slow with this type of thing. When I used the existing freeware databases when I was in grad school, including ingres, they were pretty darn slow. Again, size of tables is usually independent of the efficiency of the application running on the db. There are a different class of "in memory databases" that are commercially available that are much faster for very special situations (all in memory, no recovery, no disk so no need for log-based backups, etc). These special commercial databases should be as fast as anything. Your system is even more simple than these in memory since you don't have real transactions. RDBMS do have overhead, and like any tool you should only use them when you get some benefit out of them. Sounds like you figured out the right solution; you didn't need a tank to drive to the store. -nick