||Did you implement GOODS yourself ? How many people worked on it now ?
||GOODS was designed and implemented by myself.
If somebody made some modification or add some new features to
GOODS and inform me about it, I usually include this changes in next GOODS
release leaving reference to the author. Unfortunately, I am not able to do
everything myself (prepare good documentation, create some CASE
system for GOODS, implement various import/export utilities to transfer
data form other data sources...) I will be glad if somebody will help
me with future development and support of GOODS.
||Can you perform comparison of GOODS with other commercial OODBMSes ? Do you have some benchmark results for GOODS ?
||GOODS is distributed OODBMS and its performance is
greatly depends on application and network throughput. I didn't try to adopt
some standard benchmarks (like OO7 for example) for GOODS because
I do not like tests (say me which result you want to get and I will say you
which test you should use). If you are worry about performance of your
application, it is better to create some prototype implementation
and measure it performance. Estimation of application performance and
bottlenecks will be much more accurate in this case comparing with results
you can get runing some popular DBMS tests.
It is not so difficult to prepare interface to this prototype implementation
for different OODBMS and compare their performance. If you want I can help
you with development such prototype implementation of application for GOODS.
||Is Goods being used in any real-world
application? Do you have some "success story" list ?
Which companies are using GOODS ?
As far as I know some software companies are using GOODS, for example
Distributed Software Engineering GmbH. I do not have information about
"success stories" yet. I will be glad to receive mails with
information about projects where GOODS was used.
||How well does it scale? Did you test it with 1000 (100000, 1000000, ...) active clients.
Topology of GOODS database consists of few storage servers and
multiple clients. The number of servers should not be very high (> 10)
otherwise high synchronization overhead will cause performance degradation
and probability of making database unavailable as a result of crash
or communication failure of one of the servers becomes high.
From the other side, number of clients can be very large. It is limited only
by resources of the system and network throughput.
GOODS database server is able to perform a lot of work in parallel,
so GOODS can take advantages of SMP
architecture and perform concurrent execution of client's requests.
Sorry, I had not enough equipment to perform load tests with
large number of clients. Once again my advice is to create prototype
implementation and run it on equipment you have to perform estimation
of performance and find bottlenecks.
||How reliable is it?
||I hope you understand that I am not able to
perform exhausted testing myself (also test is a program which helps to
find bugs but it can not prove reliability of the program). So program can be
called reliable only after some time of it's intensive usage. That is one of
the reasons of freeware status of GOODS - I just hope that other developers
will help me to make GOODS more reliable.
||Are there any additional documentation for GOODS ?
||All available documentation about GOODS in english is
now included in GOODS package. Most of information is placed in
readme.htm file. There is separate description of
GOODS Java API, client-server communication protocol and JSQL.
Also text of my PhD. dissertation about GOODS in russian is available from my
homepage. I will going to extend GOODS documentation in near future, but as far
as english is not my native language, I will be glad if somebody help me
with improving quality of documentation.