[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Neil Winchurst wrote: > > Perhaps part of my problem is that I find working with a database that > has no GUI is unutterably tedious. I cannot believe that anyone uses, eg > mysql, all the time in a CLI. I do. For most serious database work you need to be able to apply changes to the structure of the database, and for those changes to be reproduced in the live system when the time comes, the most readily available method is to stick the changes in an SQL file, to record the structural changes. So I almost invariable work with a series of small files that make changes to structure, insert test data, then I go test, and when it works I copy the files that make the structural changes to the live system along with the code changes, and apply the changes to the live database. I know some of the GUIs will write these small files for you, but most of the time I find that this gets in the way. i.e. You have to know which GUI actions result in changes written to the change files, and which don't, and how to start a new file. A whole new layer of impedance mismatch. How do you do this? > I know that there are separate front end > programs to provide a GUI, I suppose I expect a program that was built > from scratch to contain everything will be superior. A separate GUI, > to my mind, written by someone who did not have anything to do with > creating the database originally, has to be some sort of compromise. I > am ready to learn otherwise. There are interfaces for managing MySQL (I much prefer Postgres to MySQL and would want a good reason to choose MySQL for a task). Pretty much all the big proprietary databases have GUIs that came later (Oracle, MSSQL) as far as management rather than development goes. Some third party tools also took hold, like Toad. So I don't think adding the GUI later is necessarily a problem, although Enterprise manager is hideous as a GUI layer. Another classic Microsoft lets stick a GUI on a command line interface mismash -- like their interface to scheduling backup for Microsoft backup. >> Most of the free software stuff has sought database independence, which >> means the Perl hackers here really don't care if it is Postgres, SQLite, >> or MySQL (at least most of the time when they are coding), and will >> choose the database to fit the scale of the client and the task. >> > Are you saying then that we will never see the equivalent of Paradox in > Linux? I didn't like Access at all, but I thought that the database > engine in Paradox was very good. Anyway I will see how I get on with > knoda connected to whatever. You still haven't said what you like about Paradox. The database engine is a relational database engine, the world is full of these. The Borland Database Engine always looked messy and cumbersome to me, which is the part I regard as the "engine". Probably because I was always dealing with SQL databases rather than things that had SQL tacked on as an after thought. It also inherited a lot of baggage from the systems it was deployed on (welcome to DOS). Far rather have a database designed to be client/server and use SQL from day one, then mess around with hideous contorted systems from the past. So I doubt it is the engine part you like, but hey I may be wrong. -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html