Reporting with db4o

Question

I've used db4o with much success on many projects in the past. Over time it seems to have evolved greatly, and with modern trends like LINQ on everyone's tongue it has peaked my interest again, especially now that I know that it is starting to support transparent activation and persistence which intrigue me quite a bit, but a friend posed a very good question to me when I first mentioned db4o and, even with modern innovation, I'm still not sure how to answer it.

What are the best/fastest/most common methods to generate reports similar to the large cross-table complex constraint reports that can be done so effectively on platforms such as SQL? I understand quite well how much time, effort and development time are saved and even many of the performance gains, especially over ORMs, but some applications require complex reports that I'm not sure how to express using objects and object queries and I am also concerned about performance, since it can be overwhelming to optimize and maintain complex reports even on systems designed specifically for that purpose.

--
Edit:

To be more clear, object data sources and the like can be used to pull db4o into the same data-rich controls as SqlDataSource et al. I've been referred to documents on the db4o site about using it with ReportViewer as well as advised to denormalize data into a reporting database, but the question is meant to pose a conceptual challenge on what can be done to accomplish the types of queries that RDBMSs perform so well on that they hold the industry. I love db4o, but I can't think of a truly efficient means of reporting on aggregate data that exists across several different types (or tables in SQL) without pulling all of the relevant objects out of the database, activating them and performing the calculations in application-level code. I may be wrong, but this seems like it couldn't hope to compete with the optimizations possible with an RDBMS.

I'm hoping amongst the bright minds we've managed to gather here that somebody knows something I don't or has innovative ideas for future implementation that could expand the ODBMS arena. I know that various ORMs implement methodologies for complex reporting objects and I'm wondering if anybody with experience with any of these technologies might have something creative that doesn't depend on any technologies outside of my code and db4o (I can generate reports with an SQL server alone).

Answer 1

My limited understanding of the issue is that currently reporting is very difficult to do with DB4O, due to some missing functionality such as Count, Aggregate, etc. As it stands, you have to implement these yourself with all the poor performance that implies (e.g. activating all records, then doing a Count operation on the records).

Answer 2

In order to work around the performance cost of reporting via db4o, I'd suggest maintaining a highly denormalized (sqlite ?) database in parallel to your db4o container. Run reports against the db and normal app logic against db4o.

Yes it's more work, but this way you'll have high performance reporting while keeping the usefulness of db4o.

If you have properly separated your data access code, it should be easy to update any code that saves objects to also update the reporting db.

Answer 3

I am not familiar with db4o. But I know some over reporting software. Some of it have a data interface that you can write your own connector like i-net Crystal-Clear. If you can query a plain list of simple objects (Strings, Numbers, ... ) then it is simple.

Another simple solution is to write a dummy JDBC driver. There is a sample for it. The queries that you want run on your db4o will be available as virtual stored procedure. With the optional parameters you can filter your data on db4o for best performance. Such dummy JDBC driver can be written 3-4 hours.

Answer 4

Please see this page.

Best,

German

Answer 5

It may also boil down to what reporting tool you use. For example, I've implemented a project which uses Microsoft's Reporting Services client-side engine to render reports - no dependency on SQL server - just feed it objects. All of the aggregation is performed by the reporting engine, which means that your code merely needs to find and materialize the underlying objects.