Re: Nearest Common Ancestor Report (XDb1's $1000 Challenge)

Jeff Brooks wrote:

[SNIP] As a DBMS developer in a past life (on both sides of the house - developing DBMS code and using DBMS's to develop an application), my opinions about what Jeff lists as shortcomings:

>
> I decided to do a quick look at the xdb1 website. I found the following
> limitations posted on the site:
>
> LIMITATIONS
> -----------
> Single-User - It is not a multi-user database.

Opinion: Critical Limitation

Single-user databases just don't cut it in heavy traffic. (Might as well put everything into 1NF and use "grep" on a Unix machine. :) )
Seriously, tho, multi-user access requires support for read-locks and write-locks, at a minimum and checking for their existance while
executing the report/query. Lock granularity becomes an issue here. If it's at the DBMS level, it may as well be single-user. If it's at the table level (does this thing have tables?) it's slightly better but can degrade to being a DBMS level for long running queries and by long running I mean anything over 1 second. Most commercial DBMS's I am familiar with lock at the row-level or the page level. This adds quite a bit of overhead to every logical access.

>
> RAM Intensive - It loads the entire database into main memory. The
> maximum database size is appoximately 4 GB with appropriate hardware.
> The maximum size will increase on 64-bit processors (ie Intel's Itanium).

Opinion: Depends on what you need.

Many implementations are moving to in-memory, especially with 64-bit machines becoming more common. The commercial vendor we use is "TimesTen" to run a 30 GB in-memory database on Sun boxes. I have also run an Oracle DBMS with over 500 GB of data on disk, so it depends on the application whether this is important or not.

>
> SQL - None. Data is managed via XDb's GUI, NLI and API. Things can be
> located via relational expressions.
>

Opinion: Limitation

(re)training staff to use a new
"language" is perceived to be a major expense by management and likely to delay the current project.  From a developer's perspective, if this is the *only* place I'm likely to use this particular set of grammar/syntax, what's the incentive to learn it if I can't use it in my next job? On the other hand, if the product is "really good" and is likely to catch on, this may not be an issue in the long term.

> Security - None currently.
>

Opinion: Major Limitation

See comments on single-user above. Same kind of logic applies here. Depending on what the granularity of the security, there may be significant overhead to verify read/write permissions for accesses.

> Transactions - None.

Opinion: TILT! The meter just went off-scale.

Without "ACID" it ain't a DBMS. It's nothing more than a glorified report-generator.

>
> Recovery - None. Regular backups, UPS, stable OS, and reliable PC
> recommended.

Opinion: Critical Limitation

Most of our customers are very fussy about this. They don't like the idea that they could lose *all* of today's new data when (not if) the system fails. If this data is financial data, they are doubly incensed. That's what transaction logs are there for, to recover the data from the last backup and to apply the logs to get to the current state. Oh yes, I forgot, there are no transaction logs since there aren't any transactions. Even with the in-memory DBMS we use (noted above), there are transaction logs, and there are multiple copies of checkpoint files (where the whole data-store is flushed to disk). If the system craps out during a flush (pun intended), the previous checkpoint is used during a restart and the transaction logs applied. Standard procedure.

> -----------
>
> Lol, xdb1 is a pathetic toy. No one in their right mind would rely on it
> for data storage.
>
> Jeff Brooks

Given that my opinions above agree with yours on at least 5 of the 6 issues you brought up, I would generally agree with your assessment (although I might have left out the word "pathetic") :)

Generally speaking, for industrial strength software, fully 80% of the work is in the hardening of the product to provide the items mentioned above, i.e. multi-user support, security, transaction semantics, and failure recovery.

[SNIP about what who owes whom.]

Just my opinion ... NPL

-- 
"It is impossible to make anything foolproof
because fools are so ingenious"
  - A. Bloch