From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | ghatpande(at)vsnl(dot)net |
Cc: | pgsql hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: First step towards Intelligent,integrated database |
Date: | 2010-12-01 13:41:59 |
Message-ID: | AANLkTikb0AppSJeDwZE7p8tNkD3OaeJmWRRtKRHq3muw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello
there was a very similar design in ANSI SQL 99. I have documentation
only in Czech, but probably you can find a sources about OOP part in
ANSI/SQL.
CREATE TABLE children(
id int primary key,
parent ref(parents)
name ..
...
and you can write queries like
SELECT name, parent->name FROM children
Regards
Pavel Stehule
see a object support in ANSI/SQL - keywords ref, scope,
2010/12/1 <ghatpande(at)vsnl(dot)net>:
> Hello,
>
>
>
> Here is the proposal: My 1st step towards Intelligent, Integrated database.
> I am explaining the proposal with the use of example.
>
> Example: We will have a master table say CustMast and a transaction table
> say salesOrder table.
>
> View of CustMast:
>
> CustCode Number(5),
>
> CustName Varchar(30),
>
> CustAdrsLine1 Varchar,
>
> CustAdrsLine2 varchar etc.
>
> View of SalesOrder:
>
> Sordno Number(8),
>
> Sorddt date,
>
> CustCode Number(5) - present way of defining.
>
> Proposed way is:
>
> CustCode Object CustMast. --- New data type to be introduced called “O”
> Object and create table definition to be modified whenever data type is ‘O’,
> it will accept object name (in this case table name). Here I want to inform
> data definition that field and its data type is already defined in master
> table and use the same data type here and both tables are linked with this
> field.
>
> We will be using same field name in both tables if not along with table name
> field name is to be accepted in create table definition.
>
> Advantages:
>
> 1. Now database knows that custcode in salesorder is a foreign key, a
> table constraint can be created. It also knows that index to be created on
> this field.
>
> 2. In present situation select statement for selecting values from
> join of both tables will be
>
> Select sordno, sorddt, custcode, custname, custadrsline1
>
> from salesorder, custmast
>
> where salesorder.custcode=custmast.custcode.
>
> 3. In proposed way we can write this statement as:
>
> Select sordno, sorddt, custcode, custname, custadrsline1
>
> from salesorder (with proper changes in program which pickup values from
> select statement.
>
> 4. Field can be from another table in same database or from Excel
> sheet column.
>
> 5. Views need not be created as all tables are properly linked with
> each other in an application.
>
> 6. This is only first step and many advantages can be a result of
> brainstorm.
>
> 7. This will change RDBMS, Tools and ERP to next generation.
>
>
>
> For any clarifications pl contact. Pl give your feedback.
>
>
>
> Regards Many,
>
> Vijay Ghatpande.
>
> Cell: +91 9822456142.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-12-01 13:49:34 | Re: KNNGIST next step: adjusting indexAM API |
Previous Message | Bruce Momjian | 2010-12-01 13:39:07 | Re: crash-safe visibility map, take three |