Re: Development of cross-platform GUI for Open Source DBs - Mailing list pgsql-general

Hello

On 11/26/06, Thomas Kellerer <spam_eater@gmx.net> wrote:
> Hi,
>
> >> I am maintaining such an application and it is neither bulky nor slow.
> >> It's all
> >> a matter of implementation.
> >>
> > Can I have a link to the application or more info on that? I would be
> > interested to take a look into it.
>
> Sure: http://www.sql-workbench.net
>

Thanks. If I ever start a project like I am thinking, your application
would be definitely of lot of help.  I have added the website in my
bookmark.

> > I have nothing against JDBC or JAVA (did my words sounded petulant
> > towards it?) but 90% of the databases do provide lowest level APIs in
> > C. Having an app in C helps us to use very very less memory (this I
> > say from my experience where I could get million record from a remote
> > server to my client at much faster rates then a another app).
>
> That might be true, but then how often do you really *need* millions of records
> on the client especially in a DB GUI where the primary task (at least that's how
> I see it) is to run ad-hoc queries or check other results.
>

Even I thought so but a newbie who works on couple of earlier project
do execute such queries and in the end it becomes a good marketing
paradigm also where you can show off that it can handle X million row
result also without any problem. Agreed, such people would be less
then 5% of the total userbase but it does gives us good
differentiating option then other GUIs.

> Which leads me to the (most important?) question: what do "we" understand under
> the term "GUI for DB" is that a full featured data-entry where a normal end-user
> can update data? Is that an admin tool for the DBA, which is intended to run
> daily DBA taks? Or maybe even some kind of ETL tool?
>

That is a very legitimate question. The project will start off as a
data entry app where a user can see all the DB objects like tables,
columns, indexes etc. Exceute queries, create db objects like table,
columns, etc. As the project becomes more mature, we add more features
for a DBA like backup, restore db, user management, log management
etc. And finally a good and state of the art query builder & designer
and if technology permits, a two-way query builder is what I intend to
target.

>  > Lot of
> > times it has happened that the C API (atleast with MySQL and PGSQL C
> > API)  provides some extra information which when smartly used can make
> > things lot efficient.
> That is true, but then a tool supporting multiple DBMS will (most probably) have
> to comprise now and then. Otherwise you'll wind up writing one tool for each
> DBMS and simply combining them under a common GUI.
>

Yes. That is exactly what I am thinking of. It definitely looks
daunting but with community support, I think it i possible. The first
and foremost thing that needs to be done is coming up with a very
flexible and pluggable architecture where I define a common set of
interface for all DBs and then what remains is to just fill in the gap
for individual databases.

This would be best done if inidividual DB expert takes up an interface
to code for their respective DB. This way we would be able to extract
the maximum juice from each DB.

> > Also, why I started a thread with wxWidgets was because C/C++ is what
> > I have been using all my life and from my experience of developing
> > couple of cross platform simple GUI, I fount wxWidgets to most mature
> > and easy to use.
>
> As I already mentioned, I'm a Java developer and naturally I find Swing most
> mature and easy to use ;)
> Actually if I look at tools that are written with wxWidgets (not that often) I
> tend to find they look less like native Windows apps as a well written Swing
> application using a recent JDK (1.5 or 1.6)

Fair enough. Maybe, there is a way where we could integrate wxWidgets
and JAVA Swing but I am not sure if its possible. Maybe, somebody can
put more pointer on this one.

>
> But that is largely a matter of taste I'd say, and everybody tends to prefer the
> environment that he/she is familiar with
>
> Thomas
>

Ritesh

>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>