D&C GLug - Home Page

[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG] Databases part 3

 

On Sat, 01 Jul 2006 17:54:17 +0100
Adrian Midgley <amidgley2@xxxxxxxxxx> wrote:

> Neil Winchurst wrote:
> > Well, I have been looking at knoda database frontend, mainly with
> > mysql. I am starting to get the hang of it all, even though I would
> > prefer to be using an all-in-one type of database, which, as I have
> > mentioned before, does not exist in Linux yet.
> >   
> I'm not sure it exists elsewhere either, for reasonable values of "all
> in one".
> Is the call actually for a _solution_ here?
> 
When I refer to an all-in-one database I mean what I believe is
officially called a 'monolithic' database. That is, the one program
includes the database engine, the gui, the search, the query, the print
a report facility, a programming language, everything. This means that
there is no need to have any other program on your computer, everything
is included in the one program. You install and away you go.

The two Windows examples that I used were Paradox and Access. Once
installed everything is there. Here in Linux, as a simple example, to
use a gui with mysql I have to install a second program, in my case
Knoda. I see that there are other frontend offerings around too.

> > However, an appeal to all you database experts out there. One of the
> > most important and useful tools for a database is the search. No, not a
> > query, a search. For example, I have a database with say 10,000
> > records. I need to look at one particular record, and I know that the
> > reference code is eg AB217.
> Again, this may not be exactly what everyone calls a database... and it
> may be best to specify what sort of database it is.
> 
The databases I wrote consisted of several linked tables and some forms
to show the records one by one. The forms could, if necessary, show
fields from two or more of the tables. The users worked with the forms
and never saw the tables. (There was more to it then that of course
including reports and queries as required.)

> A database I use and have extended from time to time currently contains
> around 150 tables.
> 
Wow. I have never had to use anywhere near that many tables in a
database.

> The idea that there is a reference code which returns one record from
> that database doesn't really fit.
> 
> A code such as 2000 given to a specific program which operates on that
> database will return a view of the entire record relating to a specific
> person, but this is pages long, categorised and requiring navigation to
> make sense of.
> 
But the search facility I am talking about does not call up tables, it
calls up a form which includes only those fields that I, as developer,
choose to include, as required by the client.

> One specific table of that database is restricted to one line (synonym:
> record) per person and thus searching that table for that person's ID or
> a unique foreign key we hold will bring up one record..
> 
> but if that was all I wanted, I'd be using a flat file, and grep.  What
> sort of information is in the database, and of what is a record composed?
> 
For example I wrote a database for a local animal rescue centre. The
data included all details of the animals, eg type, age, colour, breed,
medical details etc. Also details of who brought the animal in and
later any homing details. There were also records for the helpers, the
vets, the home checkers. All these details were held on several tables.
linked as required. 

One record would include all details about the animal, taken from
several linked tables. If one of the workers wanted to see information
about Tiddles the cat, for example, she could call up a search window
and type the name in a press enter. Up on screen would appear a form
showing all the current information about Tiddles taken from all the
relevant tables.

This is what I mean by a search, and the facility was used by all my
clients on every database I have ever created. I just don't see how
they could have used the database without it.

Regards

Neil winchurst

> -- 
> A
> 
> >  There should be a 'search' button or
> > perhaps a key combination which brings up a 'Search for a record'
> > window. I can then enter the search key (in my example AB217) and press
> > enter. I am then taken straight to the relevant record which appears on
> > the screen for me to examine.
> >
> > I can't find anything like that in any of the databases that I have
> > looked at, or perhaps I have missed something. Incidently, all the
> > Windows databases that I have ever used included a method of searching
> > for one particular record. And the facility to use wild keys (usually
> > the asterisk and the question mark) was always included too. I just do
> > not see how it is possible to use a database without this facility. And
> > no, a query will not do the job, it has a quite different purpose in
> > life.
> >
> >   
> 
> 
> -- 
> 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

-- 
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