Tim Dudgeon <tdudg...@informaticsmatters.com> writes: > There are some other things here that might deserve some comment: > http://www.h2database.com/html/features.html#comparison > > e.g. performance of embeded derby is slow!
Without qualification, such wholesale statements are close to meaningless, IMHO. It's not long ago since we saw a report on this list of a case where Derby outperformed H2 on scalability (performance with multiple threads). The only way to know is to test a particular scenario. For example, you could Derby in-memory if you didn't care about durability. One can even turn off synchronous logging to disk if database consistency after a crash isn't an issue. One can lower the default isolation mode to avoid lock contention etc. It all depends on the use case. Thanks, Dag > > Tiim > > > On 18/05/2011 16:05, malte.kem...@de.equens.com wrote: >> Hi to all, >> >> in http://www.h2database.com/html/features.html#feature_list I found >> this particular statement to above topic: >> >> *Sequence*and autoincrement columns, computed columns (can be used for >> function based indexes) >> >> Later on is a matrix that shows some RDBMs in releation to some features >> where it is denied that Derby supports sequences. >> >> So what is actually the case? And if Derby supports running numbers (in >> Oracle they are called /sequences/, in Microsoft DBs the are often >> called /auto counters/) how are they to be used. >> >> Thanks in advance for any hint >> >> Malte >>
