Re: Fwd: Re[2]: We all are looped on Internet: request + transport = invariant

From: Richard Huxton <dev(at)archonet(dot)com>
To: Dmitry Turin <sql4-en(at)narod(dot)ru>
Cc: PostgreSQL SQL List <pgsql-sql(at)postgresql(dot)org>
Subject: Re: Fwd: Re[2]: We all are looped on Internet: request + transport = invariant
Date: 2007-04-26 08:44:24
Message-ID: 46306668.10506@archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Dmitry Turin wrote:
> Good day, Richard.
>
> RH> <flight_chain ...>
> RH> <flight_options>
> RH> <flight...>
> RH> <flight...> These three flights represent options
> RH> <flight...>
> RH> </flight_options>
> RH> </flight_chain>
>
> Tag <flight_options> is un-necessary (in point of view of DBMS theory).

But that's what you're describing isn't it?
1. A journey (flight_chain) between city A and city Z consists of one or
more flights.
2. The next flight has to start at the current city, but there may be
several flights to choose from.
3. The last flight must end at city Z.

Now stage 2 groups the flights to choose among - you can call it
something else, but the equivalent of flight_options is there.

> RH> 2. If you nest flights then you'll be forced to repeat data, surely?
> RH> Multiple routes could end up mentioning flight id=123 several times and
> RH> each time have to repeat all possible options from it.
>
> Yes.
> Remember, this is not manner of storing data in DBMS.
> This is manner to visualize for man.

So how do I know it's repeated without grabbing a pencil and paper and
scrolling back and fore to compare them?

> RH> I know whether a mentioned city is:
> RH> 1. the start point of a flight
> RH> 2. the end point of a flight
>
> "city.flight" - city is start point,
> "flight.city" - city is end point
>
>>> Nearly: sorting by first section of tree
>>> (maybe by second section and so on after that)
>>> is not seggested now
>>> (user can sort, for examle, in browser by XSL).
>
> RH> Hang on, XSL is *not* easier to understand than SQL.
>
> Yes.
> This means, that it's necessary to develop TML
> (or HTML:
> http://lists.w3.org/Archives/Public/public-html/2007Apr/1380.html).

Are you sure this wouldn't just be easier if you wrote a specialised
data-visualiser application?

>>> RH> syntax for these queries isn't obvious enough to me
>>>
>>> What is not-obvious -
>>> tree notation or work with fields inside section (record) in tree ?
>>> If all of them, what is more not-obvious ?
>
> RH> If I'm going to learn only one query language, it'll be SQL
> RH> because everything uses it.
>
> 'tablename >>;' is better, than to learn php, perl, its library

But you're not doing the same thing.

>>> XML is not stored thing, it is a transport form for scheme.
> RH> Umm - xml schemas, that describe valid data for an xml document.
> RH> http://www.w3.org/XML/Schema
> RH> http://www.xml.com/pub/a/2001/12/12/schemacompare.html
>
> Term "scheme" means "database scheme" to me :)

But you were talking about XML at the time.

> RH> I'm sat here at my laptop, and I want to get a
> RH> list of flights into a spreadsheet I'm doing for my boss.
>
> Your boss will itself solve "task of travelling-salesman" ?
> By eyes ?

No, but my boss wants a list of flights from London to Madrid for next
Friday, with prices, times etc.

> RH> 1. How do I create my TML query (assuming I haven't read the TML manual,
> RH> because if I can read manuals then SQL is viable)?
>
> You start browser and open html-document on site of "list of flights".
> Html-documents send XML data to Postgres (to site).
> Postgres start function with name "main"
> http://sql4.by.ru/site/sql40/en/author/inout_eng.htm
> Function execute TML-request (it's made by authors of site !),
> and Postgres send results to your browser.
> You copy from browser into spreadsheet.
>
> Thus you don't need to write request.

So what does it matter to me as a user whether the site is written in
TML+Java or SQL+Java?

And if I'm building the site in PHP anyway (and I'm going to need
forms/buttons/etc in some language) then what am I gaining from the TML?

> You will write TML-request, if you will author of site.
>
> RH> 3. How do I get results into the spreadsheet?
>
> It depends of data model:
> if your get tree - there is no way in general case (i think),
> if your get records of only one table/view:
>
> create view x as
> select city.name as start, city.name as end, flight.t1, flight.t2, day
> from city, flight;
> x >>;

Hang on - you're using SQL. Why not just use pgadmin and paste the
results from my query if I'm using SQL anyway?

>
> then you get
>
> <x start="A" end="B" t1="5.00" t2="7.00" day="monday">
> ...
> <x start="K" end="L" t1="15.00" t2="17.00" day="sunday">
>
> RH> How does this TML setup avoid me having to write any
> RH> php/perl/etc?"
>
> Look example about site of "list of flights" above.

Sorry - you didn't eliminate any code there.

> RH> We're going to need a form that lets people choose from
> RH> a list of start and end cities, pick a date and see a list of flights
> RH> (sorted by cost, or length or some such). At present I'll build that
> RH> with e.g. PHP + SQL => PostgreSQL. What part of the process does TML
> RH> make easier?
>
> You use only SQL and small simple part (simple part !) of TML to
> transport data.

But the transport of the data is trivial, assuming I have a webserver
and PHP/Perl/ASP/etc. available.

--
Richard Huxton
Archonet Ltd

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Richard Huxton 2007-04-26 09:33:25 Re: plperlu hash problem
Previous Message Dmitry Turin 2007-04-26 08:33:02 Re: We all are looped on Internet: request + transport = invariant