QBE which is built in DBMS

Owing to the incident with me in life perhaps I will give the first the reasoned answer to questions:

    Why at the end of the 20th century in Japan with multi-billion losses the computer project of the 5th generation on the basis of physical (processors, etc.) implementations of relational databases (DB), knowledge bases and dr was failed?

    What was lost at the same time by all of us and the more so in conditions when modern computers approached a limit of miniaturization and high-speed performance (restriction of light speed), remaining still within initial (40 years of the 20th century) models Neumann's background - purely consecutive calculations?

    Why it is especially fraught for the personal computers which are still limited to structure of Intel?

History

  1) Gorbachev reorganization forced large enterprises to be exempted from big (mainframes) computers of the EU-50 above owing to repair costs and power supply, the areas. Therefore there was a problem of transfer of tasks from mainframes on Personal computers, then still Intel 386/486. First of all it concerned daily solved complex problem of an optimal complete set of products the nodes and parts arriving on assembly on the basis of plans of the enterprise, workshops. Such task at engineering enterprises of the former USSR (Bryansk, Lyudinovo, etc.) was accompanied by the whole department (about 50 employees) Luhansk PTIMASH on the basis of the multivolume project purchased long before it in Oryol.

In reorganization for lack of money (calculations with barter) the Lyudinovsky machine works offered department PTIMASH money for transfer of this task for a personal computer. The department thoughtlessly agreed and … NE could even begin work, in half a year and the management of institute having suggested to solve it to me. – My first reaction: I announced department irresponsible, and a task - NE of Intel solved on the basis of architecture: lack of a uniform cell address of RAM and channels – separate processors, in parallel with calculations (base processor) of moving a lot of CB of blocks, etc. Nevertheless agreed to an experiment: try to scroll optimization process of a complete set of products and nodes at least in 5 hours on Intel/486 instead of 25 minutes of the EU-55. At good luck (what in advance NE trusted in!) agreed to take the solution of all task (in a complex) on itself

  2) Even a computer the optimal complete set of products was solved on the EU step by step separately on workshops of the enterprise and in the conditions of absence on Intel/486 of powerful standard tools (programs) of sortings and merge it was necessary to look for essentially other solutions. From use UNIX CACHE even of Berkeley version as panaceas, was necessary to refuse to a descent. And here I for the first time addressed relational algebra and DBMS as to mechanisms of parallel (group) processing of lines of tables (data) be always on the lips requests to DBMS - the solution of a task a flow of requests (queries): transfer load from rather slow winchester to the Processor and RAM. By this time the mechanical engineering already mastered Paradox 3.5-4.5 for MS DOS and in this environment about 20 thousand and about 60 thousand parts provided me sample DB of products and nodes. The first attempt to make and start coherent (to nodes and parts at the same time) a request to this DB in the QBE language horrified: after 1.5 hours of fruitless waiting of a computer it was necessary to disconnect on the run. It was necessary to understand problems – standards of optimal designing of both relational DB, and requests and their flows, difficult calculations within language of requests, including interpolation and extrapolation, explosion of products. As a result in 2 months of the hard work time of an optimization part (process) for Intel/486 to limit for 4 hours worked well. More than 80% of this time were taken by the simple stage of complete outfitting last already relatively with irregular structure of an algorithm forcing this stage to solve already old acceptances out of Queries flow – normal serial processing of lines of relational tables (trains). Later detected inaccuracies in a complete outfitting algorithm which removal made this stage (algorithm) a flow of requests, regular with sales opportunity: time of the solution of a task was reduced to 40 minutes that it seemed improbable.

  3) The K + P magazine No. 5 (May, 1995, Kiev) on 'front page' published results of this task in the form of tests - separate very instructive QBE requests (Paradox 3.5-4.5) over the same DB of Lyudinovsky mash. The plant comparison with the identical solution in Local SQL FoxPro 2.0. In process of complication of requests of FoxPro 2.0 'exhausted', having refused to execute them (hung up) while Paradox'Y continued to work indifferently. In the editorial office of the magazine the avalanche of letters of the indignant fans of FoxPro 2.0 who were traditionally NOT using Local SQL and at the same time suspected me of anything except the main truth fell down: behind a facade of tests standards of relational technology solving of tasks on a personal computer – as method of transfer of difficult tasks of ASUP from expensive mainframes on personal computers were proposed.

  4) Exactly in a year in the same No. 5 of the K + P magazine somebody M. Vinogradov, having praised my work, reported that now with the advent of powerful SQL servers the proposed solving of tasks of ASUP a flow of Queries is provided automatically with these servers. Then I accepted it, fondly believing that any relational DBMS effectively (as well as Paradox for MS DOS) solves problems of transfer of load from the winchester of the processor by the effective organization of a buffer pool. Only in 5 years decided to check correctness of this output in practice. Now it is simpler: Took the ref. relational table of numbers from 0 to 9 (lines). From it automatically requests generated in a random way coherent among themselves (indexes) also purely numerical tables (4-5 details in line) in 1000, 10000 and 100000 lines. Then organized a test set in the form of different multitabular (coherent) Queries to this DB, a part of which included also grouping (group by). To my amazement emulated in the environment of Windows 16-i-bit Paradox 4.5 for MS DOS, using only 16 MGB of RAM, outstripped (runtime) by 200-300 times the SQL servers Interbase, MSQL (SQL-2000) and even PostgreSQL (Linux). In the same way it bypassed the descendant of Paradox 6/7 for Windows: from it (on not understanding) withdrew heart – the built-in QBE, having replaced with Interbase, thereby having actually buried Paradox. Literally for an hour sent these tests with a possibility of their check to experts of the same edition 'To + P'. – In reply failure followed: 'This NE can be because NE can be!' - the Giraffe (SQL server) of BOLSHOY (V. Vysotsky)!. – Became obvious: We live in Matrix for a long time

  5) Repeated few years ago, having complicated tests (the ref. table from 0 to 19 and the last now - about 1 million lines), having opposed in them the same Paradox for MS DOS to modern Oracle 9i: maybe all this (see above) me dreamed! But UVY! – In these tests old extremely limited by the Paradox resources saved advantage, however, only by 4 times. At the same time Oracle 9i gobbled up all resources of my modern Pentium.

Answers to questions

  1) The main reason of improbable efficiency of Paradox for MS DOS in respect of optimization of time of data processing is in the built-in QBE: the request is under construction (structure) from data to communications and the relations between them, and not vice versa, as in SQL. Additional otsutststvuyushchy opportunities in SQL:
  - the work tables Answer, Inserted, Deleted which are automatically created at accomplishment of a QBE request, etc., further effectively used in the same flow of requests
  - simultaneous accomplishment in one request of several different transactions concerning different tables, including insert, delete and update

  In passing it was succeeded to find out the possibilities of QBE significantly exceeding possibilities of SQL. - In the form of entertainment by one QBE request I managed to receive somehow from the table considered earlier (tests) about 0-9 multiplication table of Pascal (a back cover of a school notebook). Refused the offer to transfer this request to SQL of Paradox 9 DBMS, transferred from engl. approximately as: 'Want too much!'

P.S. It seems that not accidentally the author of relational algebra prof. Kodd considered the NE SQL language corresponding to relational technology.

  2) The complex problem of a complete set of products was solved by a flow approximately from 800 QBE requests which are easily read even not by the specialist in the field of programming with a text volume smaller by 20 times, than programs for the same task to the EU to a computer.

  3) In addition to the built-in QBE – certainly heart of Paradox caused admiration and the mechanism of coherent forms (Linked Forms): without regard to limitation of their communications by two levels (Master-Slave) high-speed performance in transition on displayed by a form (online) to communications almost much exceeded similar action of the Locate operator executing the same in the program. However it was not difficult to good programmer to display a layered design of communications in a real form on the limited Paradox two-level, having bypassed this restriction. Considerably this efficiency was provided with placement of screen forms, as well as given in the same buffer pool of DBMS

  4) As well as UNIX (Linux), Paradox was programmable at all levels, including generation of screen forms, report forms and even QBE requests and their processing. It allowed to generate flows of QBE requests in the same problem of a complete set of products, still repeatedly reducing texts (2) programs. The software package of a problem of a complete set of products NOT contained QBE requests (their description), but generated them in Queries flow, as well as a flow. The same Paradox property allowed to create generators of its Applications in his own environment

  5) On opportunities of Paradox 4.5 for MS DOS in generation (programmability) of QBE requests, screen forms and report forms I managed to construct the relational accounting calculator allowing the accountant most to define objects their groups, property and literally in slightly phrases (dictionary), usual for it, to set calculations for sets of objects. Each such phrase imperceptibly for the accountant generated 1-4 QBE requests executed with the maximum high-speed performance. So testing showed cost reduction and machine time for payroll PTIMASH (about 1200 persons) almost by 500 times in comparison with officially existing program in the environment of FoxPro 2.

  6) Experience defined the reason of a failure of the Japanese computer project of the 5th generation above: Prematurity of the project – lack of world experience in creation of specialized relational processors (5) type on the basis of effective solutions of the built-in QBE and other means of their generation. - Paradox for MS DOS was the unique and up to the end NOT understood solution: its first versions were focused directly on engineers and economists. As well as many other unique solutions, including UNIX, it was buried by commercial ambitions of firms like Microsoft.

  It is clear, that owing to almost reached restriction of light speed and the minimum sizes of chips sooner or later we should return to, I hope, to NOT irrevocably lost solutions, including QBE which is built in DBMS and to means of generation of QBE requests.