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

On Sun, 26 Nov 2006, Ritesh Nadhani wrote:
>
> Well, sorry if my words were confusing. I was thinking of an MS SQL
> Query Analyzer, SQLyog, PGAdmin kind of tool to start with which will
> provide a basic admin tool initially. And based upon that
> layer/architecture we will provide more advanced tools like query
> builder etc.
>
> I think I jumped the boat far too quickly, I also meant a development
> environment to be provided by this tool later on but come to think of
> it, it is already provided by OpenOffice so we wont probably need to
> think on that line.

There's room for something other than what OpenOffice provides, but a
morphed DB Admin tool certainly isn't it because they have very different
goals. I, for example, would like a toolset that helps take the drudgery
out of making a db-connected application and convert it into both/either a
more traditional client/application-server and/or a web application. I'm
sure there are a lot of people who'd like to see this, too, but these
application-perspective based needs are _dramatically_ different from
database admin needs. Combining them is bound to be more trouble than it's
worth as they have virtually nothing in common.

> So I guess, the tool that I have in mind is a database management
> interface - something like Toad for Oracle (which probably everybody
> knows).

Toad? No, everybody doesn't know. But the idea of going for a
cross-datrabase-platform db-admin tool is a fine one.

Also, repeating for emphasis my brief and incomplete "differences list:"

> > A few thoughts here; each db engine has its own;
> >
> > - sql dialect, dispite the best efforts of SQL92 et al.
> >
> > - sql query plan output mechanism and format
> >
> > - naming restrictions (some know from context what table/attribute names
> > are while others absolutely demand reserved-words remain reserved, even
> > when they'll never be found in a particular context) - presuming you want
> > to provide, "works here but not there" advice.
> >
> > - system catalogs
> >
> > - index structures
> >
> > - transaction log semantics
> >
> > - lock management - presuming you wish to include a "which transaction has
> > the lock" functionality
> >
> > - activity/error/security log systems - presuming you wish to provide
> > error resolution assistance
> >
> > - maintenance tools suite, like Postgres' vacuum
> >
> > - backup and recovery suite
> >
>
> Yes I know that. So we can make our architecture to be modular where
> each db interface use its own most efficient way rather then a generic
> way which would make things slow. And if a feature is not provided by
> a DB, that option would be just turned off for that DB.
>
> My motivation for the idea comes from the plauggable engine support
> that MySQL provides.

OK, "pluggable," but please read my words carefully and get the hint: If
you do _not_ provide features like accessing the query plans, finding lock
holders to sort out deadlocks, and these other database-specific items
listed above - and others I didn't list - you will NOT be providing
functionality that's worth the time.

Let me put it this way; Right now I have to support (at least) five
RDBMSes: Postgres, Informix, Sybase, DB2, Oracle - and we're considering
ANTS. The idea of a cross-dbms admin tool sounds great but is USELESS -
not worth my time - if it doesn't address these every-day-in-production
needs because, lets face it, I'll _still_ have to use those platform
specific mechanisms - and if I have to access them _anyway,_ why bother
with yet another tool that doesn't do the job?

The answer is, it won't have the user base you're looking for.

Seems to me, you need to get back to square one: What problem(s) are you
trying to solve? And an answer that says, "Oh, all this DBMS admin stuff
and - eventually! - an app builder too!" is not an answer I can believe as
it's too ambitious, and not focused on any core user group.

Good luck,
Richard

--
Richard Troy, Chief Scientist
Science Tools Corporation
510-924-1363 or 202-747-1263
rtroy@ScienceTools.com, http://ScienceTools.com/