Thomas

This was more along the ideas of what I had mind - I've added some
bells
and whistles, based oin my previous experience  - please comment!

Derek

<!--
NOTES:

1. Use ID for database, and table identification as these *should* be
unique...

2. Column names can be duplicated across a database - hence use name
attribute.

3. Do not store implementation details inside this file (eg. the same
database could be implemented in Oracle, mySQL etc.)

4.  Other column attributes that could be added:
  visible - yes/no for display
  length - for string/char types
  sorted - asc/desc
  default - does this column have a default value?
  defaultvalue - value of default
 
5. Different ways of supplying data to a column; via a predefined list
or a link to a another table; in the latter case, there can also be an
associated list of fields whose data must be supplied at the same time
(this normally is to ease lookup for the user)

6.  Help messages are useful (for designer and user!) - help types
might
be; popup; onscreen; url - for a http: link?

7.  Provision to be made for an indefinite number of indices... maybe
indices should be nested under each table??

8. Relationships stored separately; again, any number, with multi-field
links

9. More ideas - group columns into sets; very useful for output
purposes (logical
arrangement of related fields) - less critical for creating the
database itself?

-->

<database id="sample"> 
  <description>Store the name and favorite color of some
people</description> 
  <table id="some_data"> 
      <description>Store the people info</description> 
            <column name="Id" sqltype="integer" key="true" null="false">
 <!-- a key field --> 
            </column> 
            <column name="Title" sqltype="varchar" alias="Title">       
   
               <values type="list">
                 <value>Mr</value>
                 <value>Mrs</value>
                 <value>Ms</value>
               </values>
               <help type="???">
                  This is a helpful message.
               </help>
            </column> 
            <column name="FirstName" sqltype="varchar" alias="First
Name"/> 
            <column name="LastName" sqltype="varchar" alias="First
Name"/> 
            <column name="FavoriteColorId" sqltype="integer"> 
               <values 
                  type="link"
                  table="colors"
                  column="Id">
                 <fields>
                   <field id="Color">
                 <fields>
               </values>
            </column> 
  </table> 
  <table id="colors"> 
            <column name="Id" sqltype="integer">
            <column name="Color" sqltype="varchar"/> 
  </table> 
  <indices>
    <index name="test" table="Colors">
      <fields>
        <field name="Id">
      </fields>
    </index>
  </indices>  
  <relationships>
    <link tablestart="Table1" tableend="Table2">
      <field name="Id"/>
      <field name="Type"/>
    </link>
  </relationship>
</database> 


>>> [EMAIL PROTECTED] 19/03/2002 03:37:58 >>>
Glenn is using a setup a little different than what I had in mind.

I have not been able to find what I wanted online anywhere (though I
have
found numerous others looking for the same thing), so I have started
playing
with my own schema.  Personnaly, I have no formal database
training/education and only have a little over a years worth of
experience
playing around with databases, so my database designs are failry simple
and
do not make use of any advanced concepts (mostly because I do not know
what
the advanced concepts are).

What I have come up with so far works for me...the basic idea is that I
want
to store the same information that would be available in a schema dump
from
a database (the design, not the contents) along with a little extra
information such as the database DSN...

A small database amounts to:

<database name="sample">
        <!-- could store hostname instead and 'figure out' the dsn -->
        <parameter name="dsn" value="postgresql://localhost/sample"/>
        <parameter name="description" value="Store the name and
favorite
color of some people"/>
        <DEFANGED_object type="table" name="some_data">
                <column name="Id" sqltype="integer">
                        <parameter name="primary_key" value="true"/>
                        <!-- don't show this when rendering this table
(sloppy way to do this) -->
                        <parameter name="visible" value="false"/>
                </column>
                <column name="FirstName" sqltype="varchar" alias="First
Name"/>
                <column name="LastName" sqltype="varchar" alias="First
Name"/>
                <column name="FavoriteColorId" sqltype="integer">
                        <paramater name="link" value="colors.Id"/>
                </column>
        </object>
        <DEFANGED_object type="table" name="colors">
                <column name="Id" sqltype="integer">
                        <parameter name="primary_key" value="true"/>
                        <parameter name="visible" value="false"/>
                </column>
                <column name="Color" sqltype="varchar"/>
        </object>
</database>

.....once I figure out how to get esql to work right, I'll have a xsl
document that can parse a larger version of the above into seperate
views
for each table and proper linking between related tables (through the
'link'
parameter...what I guess is a relation).  A little later this week I'm
going
to look into PostgreSQL 'views' and see about adding in some
<DEFANGED_object
type="view"....> tags, and as I may need them in the database, some
<DEFANGED_object
type="function"..> tags....(though I'm not sure how I could describe a
function in a manner that would be useful to a xslt that has not been
customized for a specific database)...

Anyways...someone who has taken "RDBMS's 101" could likely do much
better
with something like this.....but the above sample is the sort of thing
I was
looking for...and what I have come up with works for the databases I
am
currently working with.....and since I have to build web interfaces to
6 or
so databases, using a XML setup like this is very helpful when working
with
Cocoon...for me anyways...


-Tom


> -----Original Message-----
> From: Derek Hohls [mailto:[EMAIL PROTECTED]] 
> 
> Glenn
> 
> I would definitely be interested in this - tho' I am not sure that I
> fully understand the approach you have taken eg. " submit
> queries using that format"?
> 
> I am also curious as to how you format your output to make it 
> human-readable if you do not use XSLT?
> 
> Cheers
> Derek
> 
> >>> [EMAIL PROTECTED] 18/03/2002 05:38:08 >>>
> I have been working on a similar problem but approaching it in a
> slightly different way. I have taken more of an object-relational
> mapping approach similar to products such as TopLink. Using this
> approach you define your database schema and your XML result schema
> separately and then map them together. For instance, the SQL tables
> for
> Employees (i.e. Employee, Department, Person) will be mapped
directly
> to
tf experience
playing aroun> your resulting XML document and that document can be
structured like:
>             <department>
>                         <name>accounting</name>
>                         <employee>
>                                     <firstName>John</firstName>
>                                     <lastName>Doe</lastName>
>                                     <employeeId>1234</employeeId>
>                         </employee>
>                         <employee>
>                                     .
>                         </employee>
>             </department>
>  
> or it could be structured like:
>             <employee deptName="accounting" id="1234">
>                         <firstName>John</firstName>
>                         <lastName>Doe</lastName>
>             </employee>
>  
> or any other variation.
>  
> The mapping (created against a defined mapping schema as an XML
> document) provides the information that is needed to build the
queries
> and create the resulting documents. XSLT is not used and the typical
> result type from an XML query (<table name="department"><row><column
> name="deptId">360</column>.</row>.</table><table>.</table>) is not
> used.
> The query is truly symmetric. You can define the result format,
submit
> queries using that format, and receive responses in that format. To
> qualify your query you include the known data elements and the query
> will be built to find those.
>  
> I have been working on this independently and would be interested in
> comments. I currently have the query definition, submit, and
response
> working for moderately complex data sets (involving many-to-many
> relations that can be brought to multiple places in the XML
document)
> and will work on defining insert and update as well.
>  
> - Glenn
>  
> 
>
---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
> 
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
> 

---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Reply via email to