Hello On 11/26/06, Thomas Kellerer <spam_eater@xxxxxxx> 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
