Re: Faircom c-Tree Server vs. Relational DBMS
- From: "David" <FlyLikeAnEagle@xxxxxxxxxx>
- Date: Wed, 07 Jun 2006 01:07:20 GMT
Hello Jim,
On Mon, 5 Jun 2006 11:19:48 UTC, jimwgramling@xxxxxxxxx wrote:
Thanks David, I appreciate the info!
If it's not too much to ask, can you give me an idea of how robust
c-Tree is in terms of management tasks? ... database backup and
recovery (online? point-in-time recovery?) How about security?
Maintenance -- time to rebuild indexes, reorganize files -- can these
be issues if you have large files, high transaction rates?
Our products were very reliable in terms of how the database
performed. We didn't need a terribly high transaction rate
as the product processed medical images. We had extra security
for the drives, but access to the files themselves were pretty
much open. We didn't use the protection available as it was
essentially an embedded computer (full PC network) inside an
imaging system. We didn't use the database to store our images
so database performance was just a function of the record keeping
and analysis of the images. Rebuild time wasn't bad and wasn't
needed unless we managed to corrupt the system during testing.
I was the lead developer at the time and it fell on me to keep
the database schemas and tables set up correctly. It wasn't
a big deal. I enjoyed having access to the underlying source
code when things went wrong and we needed to determine what
piece made the mistake. We did find one minor problem with
c-tree's indexing system options and got a free update for
reporting the problem and our solution. My knowledge is
also rather old (about 9 years) so I presume that there is
much more available from Faircom now. As I said in my last
note, we understood what portions of our code needed
optimization and used the appropriate level to access the
Faircom database. We generally stayed in the lower two or
three levels. SQL was used for building and upgrading the
database schemas. Performance is really up to the developer
as you should be able to make any modern processor do anything
quickly. ...just don't ask a dozen Microsoft products pasted
together with code from a beginning programmer what his
definition of fast is. I always laugh when anyone says their
machines are too slow. My curent company uses a wonderful
UI front end to generate the SQL queries for reports that
are created with a popular report generator and data stored
in Microsoft SQL. Some of the large customers have quad-CPUs
to process reports that take several hours to run. Yes, the
reports are very compute intensive, but what can a quad-Xeon
3Ghz be doing for 120 minutes just to get the SQL data.
Bascially they were tying MS SQL up in knots by trying to
process certain reports in one pass and the resulting SQL
Query was in excess of 128KB of nested queries, temp tables,
and ugly stuff. I looked at the problem for two days and
decided two SQL Queries were much better -- one to compute
the results for a temp table for the report, and one to
actually control what goes in the report. When I tested
the first pass of my solution in the lab my lowly single
2Ghz system had the final results in 47 seconds. It all
comes down to how well your tools are built and how you
choose to use them.
If I recall correctly, c-isam managed about 6,000 TPS
for analysis of our large tables on a 200Mhz CPU running
OS/2. c-isam allows you to bind a query (one time setup)
and then march through the data at a respectable rate.
Performing the same actions with a stored procedure or
a fully text based SQL request and action would be
terribly slow. You'll have to decide how much effort
to place on creating a good design and making sure the
tools are used properly. I'm pretty certain that Faircom
can handle your needs whatever they are. Politics get in
the way sometimes, so watch out for requirements (like
what database tools to use) that are dictated by management
when the developer has better knowledge of what works and
why.
Good luck,
David
I'm not asking you to rewrite the manual for me ... just looking for
any possible caveats!
;-)
Thanks again,
Jim
Rio de Janeiro
David wrote:
Hello Jim,<< snip>>
On Fri, 2 Jun 2006 19:20:23 UTC, jimwgramling@xxxxxxxxx wrote:
Hi all,
I've been working with a (potential) customer who has requested that
Thanks in advance for any help!
Jim
c-tree is a fairly full-featured database management system that
includes the source code. I used it under OS/2, two embedded
systems, and Windows. It is as good as most other database
products. The primary reasons for using such a product are
that you have the source code and that you can access your data
in the most appropriate way. They seemed to have good support
when I was using it. You can certainly stay at a revision
level if that is desired. You don't have to put up with the
release nightmares that other vendors force upon you. We
also enjoyed the ability to access the data in various methods.
We used SQL sparingly and as needed. For tables that didn't
change we used c-isam for its improved performance. That
isn't often available with other database platforms. It doesn't
sound sexy to support as most companies only 'care' about
Microsoft SQL for very obvious and wrong reasons. It is also
very cost effective.
David
.
- References:
- Faircom c-Tree Server vs. Relational DBMS
- From: jimwgramling
- Re: Faircom c-Tree Server vs. Relational DBMS
- From: David
- Re: Faircom c-Tree Server vs. Relational DBMS
- From: jimwgramling
- Faircom c-Tree Server vs. Relational DBMS
- Prev by Date: Re: user management with MySQL 5
- Next by Date: Re: Two tables with same primary key
- Previous by thread: Re: Faircom c-Tree Server vs. Relational DBMS
- Next by thread: How would you transition a company from un-normalized tables to normalized ones?
- Index(es):
Relevant Pages
|
