Re: Object Oriented Wrapper classes to SQL statements

From: Russ <rgoring_at_sbcglobal.net>
Date: 11 Dec 2001 10:04:45 -0800
Message-ID: <9d329c10.0112111004.6537c71f_at_posting.google.com>


rebner_at_checkpoint.com (Rachel) wrote in message news:<411c2c2f.0112110006.77a70687_at_posting.google.com>...
> Hello all!
>
> In our project, we allow the user to create queries on a database.
> The user is not assumed to know SQL, and has an interface that
> presents column names and lets him specify conditions.
> Currently, we work with a single table, but may extend it to multiple
> tables in the future.
>
> My question is:
> Is it possible, and is it wise, to write a set of C++ classes to
> encapsulate the structure of an SQL statement? That is, can you create
> a set of objects to model an SQL statement?
> On one hand, I would like to keep this model as general as possible
> (i.e parallels to SQL general syntax). On the other hand, if this may
> turn to be extrmemely complicated, I can use the assumption of a
> single table.
>
> If any of you know of existing packages (open source or commercial)
> that have such a model - please let me know.
>
> Thanks!

SQL can indeed be structured as a set of classes. I have implemented an web-based query solution using Java and I quess C++ would work in a similar way.

Basically, I defined classes for Query and Query fields and associated the queries to specific users or user qroups. You definately need to limit the SQL syntax but I successfully incorporated basic aggregate functions into the design as well as search criteria.

One area you need to be close attention to is with table joins. If users selected multiple tables, the join can usually be inferred from the tables.

For example, consider three tables/entities: CLIENTS, PROJECTS, and WORK_ITEMS.
Client have many projects and projects have many work items. If a user selected columns from the CLIENTS and WORK_ITMES tables, the system should automatically apply the joins between CLIENTS-PROJECTS and PROJECTS-WORK_ITMES.

This system works fine on a small scale, but I wouldn't recommend it for large databases. You would be better off using a commercial ad-hoc query product like Crystal Reports. Received on Tue Dec 11 2001 - 19:04:45 CET

Original text of this message