D&C GLug - Home Page

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

Re: [LUG] Databases part 3

 

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.

That's the Unix/GNU way - lots of small tools that work together to
provide endless permutations to suit every need. I *hated* Access simply
because it didn't suit the way *I* wanted to query the data. Any one
programme has masses of assumptions that are based almost exclusively on
the preconceived bias of the original developer(s). Making an all-in-one
solution for me will not suit you, making one to suit you won't suit
Simon etc.etc.etc. Why else does GNU have KDE *and* Gnome plus a host of
other window managers that can be used to create a truly customised
desktop? Choice - the fruit of freedom. Don't knock it, work with it.

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

Semantics. What you are actually looking for is a database schema that
suits your assumptions. Nevertheless, what you need is a query.
Everything in a database manager is a query. Searches are performed
using queries. DELETE, UPDATE, DROP, INSERT and CREATE are all queries.
Everything you do with a database manager programme is just another
query. You cannot search any database, you can only query it - this is
true on GNU precisely as it is on Windows and every other OS.

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

So you need a schema that includes a key on the reference code field.
i.e. Your database schema (the tables, the fields and how you divide up
the data between them) needs to match your assumption of how you will
find data in the database.

> There should be a 'search' button or
> perhaps a key combination which brings up a 'Search for a record'

SELECT * from table_name where reference_code = "AB217";

Probably the simplest GUI to do this is a HTML form:

<form action="ref.php" method="POST">
<input type="text" name="reference_code"><br>
<input type="text" name="table_name"><br>
<input type="submit" value="Search!">
</form>

And then a bit of PHP:

<?php
$reference = $_POST["reference_code"];
$table = $_POST["table_name"];
@mysql_connect(....


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

LAMP can do that for you with the minimum of fuss.
http://www.codehelp.co.uk/php/mysql2.php


> I can't find anything like that in any of the databases that I have
> looked at, or perhaps I have missed something.

You have, you've misunderstood the concept of "Query" and the purpose of
the "where" command. Leave "search" to google (which turns your search
into a query and prints the results).

> Incidently, all the
> Windows databases that I have ever used included a method of searching
> for one particular record.

Correction. All windows GUI-front-ends to databases ...

The underlying database has ALWAYS had to translate the GUI command into
a query, in most cases SQL precisely as above.

> And the facility to use wild keys (usually
> the asterisk and the question mark) was always included too. 

The above query would easily allow wildcards because the query itself is
passed directly to the database manager: mysql.

Database: Ultimately, just a file.
Database Manager: The application that runs queries against the
database. (All operations are a query, even DELETE, INSERT and DROP).
Database FrontEnd: LAMP is actually the most common, by far - it doesn't
matter if the 'P' is for PHP or Perl. Virtually every scripting language
has bindings to MySQL and compiled languages have multiple API's for
many, many database queries. See QOF:
http://qof.sourceforge.net/

For wildcards:

SELECT * from table_name where reference_code like "AB217%";

(matches all reference_code fields where the value begins with AB217, so
it matches AB217, AB2171, AB217A, AB217435kjs452hf78sd etc.)

> I just do
> not see how it is possible to use a database without this facility. 

Of course, that's why every GNU database supports everything you desire
- just not in the way that your assumptions have led you to expect it.

> And
> no, a query will not do the job, it has a quite different purpose in
> life.

Untrue. All database manager operations are just queries. SELECT is a query.

> 
> Or am I not seeing something here? Any help/comments from the experts
> out there will be welcomed.

I recommend you get down and dirty with a command-line database manager
like MySQL (helpful slides here:
http://www.dcglug.org.uk/linux_uk/mysql1.html )
and then reassess your terminology.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


Attachment: signature.asc
Description: OpenPGP digital signature

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