>From experience I found the that the best way to preserve the knowledge and to document it when designing an application or a database alone is to use a CASE. Better still use a CASE that can use as targets multiple platforms
This way the documentation of different aspects of the schema if we talk about databases is independent of what platform you use to implement you project. This documentation can then be embedded in the schema at generation time. A good CASE can also reverse engineer a database schema and the documentation embedded in it (field descriptions, clear text constraints, comments within the code, etc) They can also generate the scripts to export/import data in tables. I've seen good examples of FLOSS projects that can be used as CASE tools in previous messages in this forum, tools that can be used against both commercial and non-commercial RDBMS engines. Most of the time you'll find that finding your way through a data schema that has little documentation embedded in it is fairly easy and is the least of your problems when dealing with debugging, developing or porting the database. This is not to say that documenting your code is not a good practice. By far a documented schema is preferable to a non-documented one. On Mon, 2006-03-20 at 22:01 +1200, Christopher Sawtell wrote: > On Friday 17 March 2006 11:21, Nick Rout wrote: > > On Thu, 16 Mar 2006 17:32:04 +1300 > > > > Christopher Sawtell wrote: > > > On Thursday 16 March 2006 16:04, Roy Britten wrote: > > > > On Thu, 2006-03-16 at 15:54 +1300, Don Gould wrote: > > > > > Is there any kind of gui tools that > > > > > you know of for postgres? > > > > > > > > pgAdmin III http://www.pgadmin.org/ > > > > > > Also you could use the sql:// protocol in Konqueror. > > > > > > imho using these click and point gui tools is a somewhat hazardous > > > exercise, because they don't, as a general rule, conveniently save a > > > .sql source code file from which you can rebuild the database from > > > scratch. > > > > Yes but at any stage you can dump the database generating scripts - wel > > you can in mysql, I assume you can in postgresql too. > Yes you can do that in PostgreSQL, but you then lose all and every syllable > of documentation you have put in the sql source code file. I may be a > traditionalist, but I recon that if you are trying to build a project or > product which has a life, rather than a quick fix for some immediate > problem, then it's essential to have source code that's understandable and > usable by other people.
