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

Поиск
Список
Период
Сортировка
От Richard Huxton
Тема Re: Fwd: Re[2]: We all are looped on Internet: request + transport = invariant
Дата
Msg-id 46306668.10506@archonet.com
обсуждение исходный текст
Ответ на We all are looped on Internet: request + transport = invariant  (Dmitry Turin <sql4-en@narod.ru>)
Ответы Re: Fwd: Re[2]: We all are looped on Internet: request + transport = invariant
Список 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


В списке pgsql-sql по дате отправления:

Предыдущее
От: Dmitry Turin
Дата:
Сообщение: Re: We all are looped on Internet: request + transport = invariant
Следующее
От: Richard Huxton
Дата:
Сообщение: Re: plperlu hash problem